expand_less
As I write the first version of this, its foundational architectural elements have not yet been built. Ceptr is a work in progress without a fully formed and defined API, and Decko the platform hasn't quite yet emerged from Wagn the web application. The last three chapters are not yet written and they concern issues of central importance for Cetpt Cards to become possible. We will proceed to describe Ceptr integration with cards as if we already had these fascilities available for implementation. This isn't all bad as it may help the tool builders concentrate on the most important work.
Both Ceptr and Decko are development platforms and support the idea of extending or, really completing, the platform with custom applications. This means that we will need integration components on both side. As a Ceptr developer, one implementation choice would be to read and write card data directly, maybe through Rack based middleware interfaces to maximize in-process advantages, maybe through ruby/go cross APIs via ffi, or less integrated configurations with networked connections between system components.
Alternatively, the Decko interacting Ceptr instances might choose not to access card based data, and instead would support Decko applications by exporting a representation of it's data to the Card based API and be a component of the networked card model to be described in [[Cards on the Move]].
It would also be simple enought to arrange for Decko events from life cycle events on stored cards to trigger ceptr actions at the edges. If you needed to, you could even coordinate with sub-action events, for example reading or initializing a new card, before, after or around validation or commit, etc. New cards with signatures and signed objects could be created with fine grained control through interfaces already defined and in use in implementing {{Wagn}} or {{Wikirate}}.
As a Decko developler, I want to provide access to holochain based services and seemlessly integrate trust based services with card applications. We will need/want various services from Ceptr based agents. From the Decko/ruby side, I can implement an exportable view of ceptr and holochain information as cards. It is a matter of programming ceptr instances to respond to a protocol the provides what the Decko app needs.
One thing is pretty apparent, all of this will require programming on both sides of the interface. It is likely that some features and functions need to be available on both sides and it will be hard to tell if you are working on a ceptr interface for decko or a decko interface for ceptr. Could be many of the system components will be used in both directions.
Both Ceptr and Decko are development platforms and support the idea of extending or, really completing, the platform with custom applications. This means that we will need integration components on both side. As a Ceptr developer, one implementation choice would be to read and write card data directly, maybe through Rack based middleware interfaces to maximize in-process advantages, maybe through ruby/go cross APIs via ffi, or less integrated configurations with networked connections between system components.
Alternatively, the Decko interacting Ceptr instances might choose not to access card based data, and instead would support Decko applications by exporting a representation of it's data to the Card based API and be a component of the networked card model to be described in [[Cards on the Move]].
It would also be simple enought to arrange for Decko events from life cycle events on stored cards to trigger ceptr actions at the edges. If you needed to, you could even coordinate with sub-action events, for example reading or initializing a new card, before, after or around validation or commit, etc. New cards with signatures and signed objects could be created with fine grained control through interfaces already defined and in use in implementing {{Wagn}} or {{Wikirate}}.
As a Decko developler, I want to provide access to holochain based services and seemlessly integrate trust based services with card applications. We will need/want various services from Ceptr based agents. From the Decko/ruby side, I can implement an exportable view of ceptr and holochain information as cards. It is a matter of programming ceptr instances to respond to a protocol the provides what the Decko app needs.
One thing is pretty apparent, all of this will require programming on both sides of the interface. It is likely that some features and functions need to be available on both sides and it will be hard to tell if you are working on a ceptr interface for decko or a decko interface for ceptr. Could be many of the system components will be used in both directions.