{"id":52038388,"url":"https://github.com/adobe/substance-3d-connector","last_synced_at":"2026-08-01T21:07:03.642Z","repository":{"id":232411127,"uuid":"758143602","full_name":"adobe/substance-3d-connector","owner":"adobe","description":null,"archived":false,"fork":false,"pushed_at":"2025-04-10T17:58:14.000Z","size":234,"stargazers_count":114,"open_issues_count":2,"forks_count":8,"subscribers_count":13,"default_branch":"main","last_synced_at":"2026-02-20T19:06:50.664Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/adobe.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-02-15T17:53:03.000Z","updated_at":"2026-01-30T11:50:12.000Z","dependencies_parsed_at":"2025-03-14T22:20:01.351Z","dependency_job_id":"cf6f5e6d-81d2-47db-bbc3-797078208ee3","html_url":"https://github.com/adobe/substance-3d-connector","commit_stats":null,"previous_names":["adobe/substance-3d-connector"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/adobe/substance-3d-connector","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/adobe%2Fsubstance-3d-connector","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/adobe%2Fsubstance-3d-connector/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/adobe%2Fsubstance-3d-connector/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/adobe%2Fsubstance-3d-connector/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/adobe","download_url":"https://codeload.github.com/adobe/substance-3d-connector/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/adobe%2Fsubstance-3d-connector/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":36170560,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-07-20T02:08:10.276Z","status":"online","status_checked_at":"2026-08-01T02:00:05.789Z","response_time":100,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-08-01T21:07:03.218Z","updated_at":"2026-08-01T21:07:03.637Z","avatar_url":"https://github.com/adobe.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Substance Connector\n\nSubstance Connector is a communication framework for connecting applications\nto one another to share generic data. Our initial use case is to automate and\nsimplify the process of exporting and importing assets between applications. \nThis framework can be expanded for use in sharing any data between applications.\n\n\n--------------------------------------------------------------------------\n    CLI Tools and Default Build\n--------------------------------------------------------------------------\nThe default cmake project build will create the python project folder for\nthe CLI tool set. The CLI tools act as a connector endpoint and can be used\nto test features and/or integrations of Substance Connector. The CLI tools also\nacts as a recommended example of how a connector integration is structured.\nThe CLI tools are written in Python but the structure remains the same for all\nlanguage implementations. The default install directory will either be\n./install or ./cli/install based on if cmake is run at the root or within the\n./cli folder respectively.\n\n--------------------------------------------------------------------------\n    Running Unit Tests\n--------------------------------------------------------------------------\nConnector comes with a suite of unit tests for testing both the core library\nas well as the cpp-module. Setting the cmake variable CONNECTOR_ENABLE_BUILD_TESTS\nto true at cmake initialization will enable building of the test applications.\nThese tests can be ran post build by running CTest.\n\n--------------------------------------------------------------------------\n    Implementation Details\n--------------------------------------------------------------------------\nThe core library is implemented in the C programming language, allowing it to\nnatively bind to most any existing programming language with little effort.\nAlmost every language allows to bind to native C code.\n\nThis allows the core module to be used in conceivably any language that has bindings\nto C, although certain things like function pointers may become difficult,\ndepending on the FFI of the language.\n\n\n--------------------------------------------------------------------------\n    Using the Framework\n--------------------------------------------------------------------------\nThere are build flags listed in the top level of the cmake. The build flags\ncan be enabled for choosing which language wrapper for the current environment.\nOne flag should be enabled at a time and it will create all of the relevant cmake \ntargets. Enabling more than one could lead to build errors or unused cmake targets.\nFor example, enabling the QT module flag will build core, C++ module, and\nthe QT module. If no flags are set, the project will default to building the CLI\ntools. The CLI tool is a standalone connector instance and can be used for \ntesting and can also be used as a reference for how an integration is structured.\n\nGeneral lifecycle of an integrations:\n- Create instance\n- Create feature components\n- Bind callbacks to components\n- Initialize instance\n- Broadcast that a new instance is available\n- Shutdown\n\nConnections are automatic once a broadcast message has been sent. Every existing connector\nend point will have context of a new connection and vice versa.\n\nConnector is a multi-threaded framework and callbacks will be called on a new\nthread. Thread safety is up to the user for callbacks.\n\n--------------------------------------------------------------------------\n    Expanding the Framework \n--------------------------------------------------------------------------\nMessages are sent using a string. We use json as a string for formatting\nmessage structure but this can be used however the user sees fit. All that is\nneeded is to create a new derivative of the module base class. As an example, \nthe application.h file in the C++ module is the base for feature components and\nexport.h is an implementation of a feature. In this instance, we are creating a\nfeature component that handles sending and receiving of assets that do not need\nany additional context for exporting and importing. For adding a PR of a new feature/\nschema, json is expected and an implementation is expected in all language modules.\n\n--------------------------------------------------------------------------\n    Coding Style\n--------------------------------------------------------------------------\nThe naming convention for functions is as follows:\n    * All externally facing functions shall be prefixed by substance_connector\n    * All internal functions that do not have static linkage are prefixed\n      by connector (code inside the details folder)\n    * All static functions need not be prefixed by either\n\nSome internal headers have compatibility with C++, in order to leverage C++\ntesting engines with internals of the libraries. This isn't a requirement,\nbut may be needed for testing to ensure proper linking.\n\nAll external headers must be wrapped in extern \"C\" declarations for C++\ncompatibility, with the corresponding test for C++ defines so that they\nmay also be used in C.\n\nHeaders must have a guard statement with the format _SUBSTANCE_CONNECTOR_\u003cHEADER\u003e_H\nto ensure reasonable header define namespacing.\n\nExternal headers should be located in the include/substance/connector folder,\nmeaning that with include as an include directory, an application can\ninclude a header with #include \u003csubstance/connector/\u003cheader\u003e.h\u003e. All headers\nused internally must be in the details subfolder, so they can be included\nas #include \u003csubstance/connector/details/\u003cheader\u003e.h\u003e by any internal file or\nby the testing suite.\n\nAll macro flags to be respected at compile time (wrapped in ifndef flags)\nmust be prefixed with SUBSTANCE_CONNECTOR. Flags that are shared between files,\nsuch as in a header, must use the same prefix. Macros used within a single\nfile should be prefixed with CONNECTOR.\n\nEnum constants shall also use the SUBSTANCE_CONNECTOR prefix, and be in all caps,\nif they are included in a header. If the enum is local in scope to a\ncompilation unit, such as inside of a .c file, they should be prefixed by\nCONNECTOR and should also remain in all caps.\n\nTypedefs for structure types or enum types should have the format connector_\u003cname\u003e_t\nif internal, and should have the name substance_connector_\u003cname\u003e_t if they are in an\nexternal header. Function pointers will have the same convention, except with\n_fp at the end instead of _t.\n\nStructures generally have the form struct _connector_\u003cname\u003e, with the corresponding\ntypedef as connector_\u003cname\u003e_t.\n\nLines should generally be kept at 80 characters or less. There may be function\nsignatures that need to break this.\n\nSnake case should be used for both variable names and for function names.\nAllman-style braces should be used, with four spaces for indentation.\n\nVariables should always have an initial value, unless some form of struct.\nPointers must be initialized to a value or to NULL. Integers should be\ninitialized to an intentional value or to zero.\n\nPointers should be declared constant if they are not modified, unless the\ninternal function reserves the right to modify it.\n\nMemory allocations must go through the proper connector_allocate and connector_free\ncalls, to ensure a standard memory allocation throughout the codebase. The\nAPI allows for changing the allocator and free function before initialization.\n\nRationale - There is a lot of system-specific code that occurs here. There\nshould be as few surprises when going into a piece of the codebase, as it\nshould look similar to the whole. It is also a C codebase, and should follow\nconventions that are different than the C++ codebases that are typical to\nto integrations.\n\n--------------------------------------------------------------------------\n    Compile flags \n--------------------------------------------------------------------------\nThere are some define flags that are open for input at compilation. They\nhave not all been documented here, but some of them are the following:\n\nContext count - The amount of contexts available can be compiled in:\n    SUBSTANCE_CONNECTOR_CONTEXT_COUNT\n\nselect vs. poll - There are platform defines for each of these, but it will\n    honor if the following are set:\n    SUBSTANCE_CONNECTOR_FORCE_SELECT\n    SUBSTANCE_CONNECTOR_FORCE_POLL\nIf both are set, it gives precedence to select\n\nInbound and outbound thread count - Inbound and outbound worker threads can\n    be set separately, with the following:\n    SUBSTANCE_CONNECTOR_INBOUND_COUNT\n    SUBSTANCE_CONNECTOR_OUTBOUND_COUNT\n\nDispatch thread count - The number of dispatch threads can be set with\n    the following:\n    SUBSTANCE_CONNECTOR_DISPATCH_COUNT\n\nSocket backlog count - Number of connections to allow on a listen call\n    SUBSTANCE_CONNECTOR_SOCK_BACKLOG\n\n--------------------------------------------------------------------------\n    Bindings\n--------------------------------------------------------------------------\nCurrently supported language bindings:\n\nC, C++ (Natively)\nPython 2\nPython 3\nTcl\nHaskell\nQml\nSBCL Common Lisp\n\nTested build platforms (just C):\nLinux (x86-64, arm-musl-32-bit, arm-musl-64-bit, PowerPC 32-bit)\nMacOS (x86-64)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fadobe%2Fsubstance-3d-connector","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fadobe%2Fsubstance-3d-connector","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fadobe%2Fsubstance-3d-connector/lists"}