Service Framework APIs for Hyperty Developers

[acheambe]

An ongoing discussion between T3.4 partners and the rest of WP3 and maybe also WP5 as this has a direct impact to your objectives too. But anyone is free to join this discussion.

Objectives:

• Identify what functionalities the developers will use directly from the Runtime APIs
• Specify APIs for creating and managing Data Objects defined in D2.2
• Specify templates for creating basic Hyperty Types (communication, context and Identity)
• Identity other common utility functionalities that can be provided.

[pchainho]

Identify what functionalities the developers will use directly from the Runtime APIs

As currently designed, Hyperty developers would just have to send messages through msg bus.postMessage() functionality. The framework could provide a MessageFactory to create messages according to the Message Data Model to be send through the message bus. Another possible framework functionality is to parse received messages from the message bus to extract new objects or to "feed" existing objects.

[acheambe]

Okay, I have started gathering and specifying the functionalities for the MessageFactory in the link below. https://github.com/reTHINK-project/core-framework/blob/master/docs/specs/service-framework/sf_message_factory.md

A similar specification will be done for the other Data Models as well.

[pchainho]

Some drafts ideas for a higher level API to support data synchronisation among Hyperties:

Reporter creates a data object passing as input parameters invited observers, the data object schema and the handler that will process events from observers (eg observer added, observer removed, observation request by a non invited observer):

DataObjectReport <Promisse> createDataObjecReport(schema, observers, (?) handler)

This function should implement the generic procedure to setup a data synchronisation

As soon as the promised data object is returned, the reporter can start updating the object and the syncher will update observers with data object changes. The data object should also provide functionalities to add and remove observers.

On the other hand, the framework can provide an API to create observations with invitations received from reporters passing an handler to process observation/reporting events (eg new report, report end, report error):

DataObjectObservation createDataObjectObservation( invitation message, handler )

The DataObjectObservation would provide functions to accept, reject and stop observation. DataObjectObservation would have as attributes, its schema and url. As soon as the reporter changes the data object, the Data Object would also change on the observer side.

These functions would implement the generic procedure to setup a data synchronisation

[pchainho]

I suggest all data object factories has a constructor that takes as input the json schema of the data object

[acheambe]

I suggest all data object factories has a constructor that takes as input the json schema of the data object

@pchainho during implementation i have not seen the need of the schema as input for the constructor? What was your idea here? what should the constructor do with the schema?

[pchainho]

to be used to validate the created object against the schema