rfc-183 Cloud Scope for preferences about design HOT 6 OPEN

Comment author: @juergen-albert

In a cluster/cloud globally available preferences become necessary. These can be used to e.g. configure database connections that are available to everybody in the cloud.

It might also be nice to provide a kind of filter mechanisms, so I can add a property and make sure, that is only visible to nodes with a certain tag. This can e.g. be useful if we have a cluster providing services to different tenets. So you can make sure, that the preferences are only available on nodes, the tenet is allowed to use and don't and on the node used by somebody else.

from design.

Comment author: @tverbele

It actually is possible to attach other, custom properties to a NodeStatus service, however currently only by creating your own NodeStatus provider implementation that has those properties.

Question is whether we need a mechanism that any bundle can add properties to a NodeStatus service, or whether this bundle just needs to publish his own NodeStatus service with the (extra) properties he wants to publish?

Filtering is hard - if not impossible? - to include in the spec. You can probably provide your own filtering mechanism using service hooks that hide certain NodeStatus services for other tenants.

from design.

Comment author: @maho7791

This bug is related to the PreferenceService.
There are currently two scopes defined, system and user.
I think what Juergen meant, was to introduce another scope 'cloud', two store cloud related preferences.

This could also mean to have a different storage for these kinds of preferences.

from design.

Comment author: @juergen-albert

As discussed: We have to take a closer look in the OSGi Preferences Service. We obviously messed this up with the Eclipse Preferences Service. Thus a Cloud Preference Service appears to be an RFP in and of itself.

from design.

Comment author: Castro B <[email protected]>

Hi Jürgen Albert is this issue has been solve already?
about the SYSTEM and user.

Castro B,
http://webtrafficgeeks.org

from design.

Comment author: @juergen-albert

@ Castor B No, we never took a deeper look into this topic.

from design.