Skip to content

Embedded interfaces

Jump to bottom Edit New page
jamiebullock edited this page Feb 21, 2013 · 1 revision

Initial planning for Embedded Interfaces

The purpose of this document is to identify the necessary steps for the implementation of a capability to embed interfaces in saved integra files, such that files saved in any IntegraLive installation can be loaded in any future IntegraLive installation, even when 3rd party developers are creating optional interfaces, and interfaces are evolving over time. This work will be done in two phases:

Phase 1 = ensuring that saved files are embedded with the interface definitions and implementations they use, so that future versions will be able to treat these files identically even if interfaces have been removed or modified.

Phase 2 = adding all other necessary functionality needed for the launch of an 'interface developer sdk' intended for use by 3rd party developers.

Representation of Integra Interfaces

  • We need a way to tie Interface Definitions and Implementations together (interfaces currently consist of xml IID files, implementations consist of a tree of .PD files). We could either embed the PD implementation tree as xml nodes within the IID file, or we could use a zip file in which the pd tree was stored in a directory structure. In either case these files will be called 'II' or 'Integra Interface' files. Phase 1

  • We need a way to distinguish different versions of a given interface. Modification Stamp is insufficient. We should use a 2nd guid or a checksum. Phase 1

  • We need to expand the existing .integra format to contain embedded II files for each interface used in the file. Phase 1

  • We need a way to distribute 'bundles' of integra interfaces, so that 3rd- party developers can deploy collections of interfaces onto users' machines. Possbly via autogeneration of platform- specific installers? Or giving IntegraLive gui a capability to load II collections, and deploy them as needed? Phase 2

Developer Tool

  • We need to expand the functionality of the existing IID editor tool to include the ability to embed pd implementations, and to output the new II files instead of current IID files. Should rename the tool to something like 'Integra Interface Creator'. Phase 1

  • This will require the capability to walk the pd abstraction tree, to automatically find all abstractions used by each PD file. Phase 1

Module Host

Tidying up existing use of abstractions and externals

  • We should start using vanilla PD instead of PD- extended, and include within libIntegra installations only the externals that are necessary for our existing core modules Phase 1

  • We should modify the way we deploy the existing set of modules so that they are all contained within II files, instead of separate IID and PD directories Phase 1

Instantiating modules from different locations

  • We need to research & implement a way to specify paths of modules to instantiate at runtime Phase 2

LibIntegra

  • On startup instead of loading the set of installed IID files, we should load the set of installed II files, and extract the PD implementations to a temporary directory phase 1

  • Update 'save' command to embed II file into integra file for each interface used within the file phase 1

  • Update 'load' command: phase 2

    • deploy embedded implementations to somewhere within temp directory
    • add interface definitions from loaded file to in- memory representation of interface definitions
    • if file doesn't contain embedded interfaces, refer to system- installed interfaces where available (backwards compatibility for old files)

  • Update 'new' command: phase 2

    • caller specifies which version of interface to load
    • command somehow sends path to correct version to host instantiation call

  • Update 'delete' command: phase 2

    • if interface of deleted node was embedded in a 'load' command, and interface is no longer in use by other nodes, delete embedded implementation and remove in- memory representation of interface definition

  • New 'substitute' command, to swap a module for another version of the same module phase 2

GUI

  • Update the set of interface definitions after load and delete commands. Either by updating entire model or by some new push- mechanism from the server phase 2

  • Update the use of the new command, to take advantage of libIntegra's new api, in which interfaces will be specified by version id instead of interface id phase 2

  • Update the module library to show interfaces grouped according to types: core, 3rd party bundles, project- local. Potentially add other new functionality to module library, such as grouping / filtering according to tags. phase 2

  • Implement gui for upgrading modules (substituting the latest version, or substituting different versions where > 2 versions are available) phase 2

Documentation, templates

  • Write documentation & prepare template II files for 3rd party module developers phase 2
Add a custom footer
Add a custom sidebar
Clone this wiki locally