Here to store data pertaining to multiple runtimes

[rjflp]

I'm opening this issue to discuss where to store multi-device data from a user.

Users will have the need to share data among several devices (runtimes). If this data belongs to a particular app or hyperty, then it is up to that app/hyperty to store it somehow. The Service Provider should handle this. However, there is data that does not belong to single App/Hyperty, such as: user policies, graph connector data (?), user identity information (?). Also, we may wish to persist runtime configuration information outside the device.

Several possibilities for storing this data have been discussed in several fora. So far, these include:

• Assuming that this is a convenience service and not a part of the core framework. As such, it could be provided by a hyperty provided by a Service Provider. Service Provides would compete to provide this service. Users would select a SP and install its hyperty in their devices. This would require that hyperty to read and write local policies. Users would have to explicitly allow this.
• Store this in the Global Registry. This is not what the Global Registry was designed for, and there would be performance and capacity limits. As the data in the Global Registry is public, data stored there would have to be ciphered in a strong way.

In order to kick off this discussion, I would suggest that whomever needs this functionality to describe their requirements, namely: volume of data to store, update frequency, privacy concerns, data sharing scope (all the devices of a user, a single device, etc).

[pchainho]

I like the first option, a generic P2P Data Sync hyperty plus a data back-up Hyperty would fit well here.

This would require a small additional functionality in the Policy Engine namely to have a listener registered in the msg bus (eg runtime:////pe) to receive Read, Update and Delete messages from the Hyperty. These messages would still be subject to policy engine authorisation itself

[sgoendoer]

Two things:

Regarding to what kind of data needs to be stored/synched here:
From TUB side, I guess this would be the address book/graph connector data including the list of known contacts, possibly with additional information such as call/communication history, group association of contacts, starred/prioritized contacts etc.

Regarding to where to store this:
If I get Paulo right, there could be a CSP now that offers to store this sync data. So this CSP would be registered in the GReg and the corresponding Hyperty would be "discovered" via the DReg, so the data can be fetched from here. Plus, the user could choose between different providers for this kind of sync service.

What we would need is a) a service for storing the data, b) a (mandatory?) hyperty to fetch the data, and c) a data format and sync mechanism (I guess).

[rjflp]

If I get Paulo right, there could be a CSP now that offers to store this sync data.
I agree.
So this CSP would be registered in the GReg and the corresponding Hyperty would be "discovered" via the DReg, so the data can be fetched from here. Plus, the user could choose between different providers for this kind of sync service.

I don't think it has to be "discovered" in the Global Registry. No one else will use it. It just has to be configured in the runtime.

What we would need is a) a service for storing the data, b) a (mandatory?) hyperty to fetch the data, and c) a data format and sync mechanism (I guess).

a) yes
b) not really mandatory. We need a hyperty, from a service provider.
c) It has to offer the proper API/Data Format but I think that the sync mechanism is "implementation specific"