Hi Marius I like the general direction of your proposal. The only concern I have is that you require properties on the services (sling:friendlyName and maybe sling:resourceType). Since this requires modification of the service implementation this cannot flexibly be used by downstream users of this feature.
However, if you require some JCR node structure as a skeleton for the hierarchy in any case, why don't you just reference the service/service-factory from a property on the respective nodes? This would allow: * fine or coarse grained access control as required, * flexible placement/naming of the hierarchy (e.g. it would be possible to map replication services into /etc/replication and other sevrices to /system/...) Regards Julian On Thu, Feb 20, 2014 at 1:12 PM, Tommaso Teofili <[email protected]> wrote: > Hi Marius, > > 2014-02-20 9:58 GMT+01:00 Marius Petria <[email protected]>: > >> Another idea was proposed to generally solve access to OSGI objects >> (configs and services). >> >> 1. OSGI configs need to be managed (CRUD) over HTTP and access should be >> controlled at factory and config level. >> >> URL hierarchy: >> - /system/osgiconfigs/factoryPid/{configFriendlyName} >> - configFriendlyName will be provided in a OSGI config property >> sling:friendlyName >> ACLs are controlled via representative JCR nodes: >> - root node /system/osgiconfigs - controls access to the whole hierarchy >> - intermediate nodes are optional, a node like >> /system/osgiconfigs/factoryPid controls access to managing configs of a >> certain factory >> - implementation will be done using a ModifyingResourceProvider and access >> will be secured with a ResourceAccessGate >> >> > looks good to me, especially because this is a generic solution that can be > leveraged for other use cases. > > >> Questions: >> - should we expose all configs or only selected ones (for example those >> that have the property sling:friendlyName)? >> > > being this a generic proposal affecting all the existing configs, maybe > it'd be better to not expose anything by default. > > >> - should we use a ResourceProvider per factory in order to customize the >> provider better. > > > maybe it'd be good to have a generic one that works on a config factory > resourcetype and then that could be overridden by a custom one in case it's > needed. > > >> The following customization options are useful: >> ---- define a custom root for config factory (for example >> /etc/replication/config) >> ---- define exactly what properties are exposed from configs belonging to >> a factory by using a whitelist. > > >> 2. OSGI services need to be exposed over HTTP in order to make it easy to >> link them to servlets that execute actions on them. >> URL hierarchy: >> - /system/osgiservices/servicePid >> - services should have a property to (sling:resourceType or different) >> that will be used as the resource type of the associated resources >> - servlets can use the designated resource type to bind and execute >> methods on the associated services. >> ACLs are controlled via respresentative JCR nodes >> - root node /system/osgiservices is mandatory and controls access to whole >> hierarchy >> - sub nodes are optional and allow fine grained control at service level >> - implementation will be done using a ResourceProvider and access will be >> secured with a ResourceAccessGate >> >> > looks good to me, I'm not sure about the property to be used for the > resourcetype, however that's just a detail. > > >> Questions: >> - should we expose all services or just the ones having the designated >> property? >> - should we use a ResourceProvider per service interface so that we can >> customize it better? >> ---- define a custom root node for a service interface (for example >> /system/replication/agent for ReplicationAgents) >> >> > probably same as above, no service exposed by default. > > >> >> This is just the initial proposal. Feedback will be greatly valued on the >> general approach, but also on the particular questions of whether a single >> hierarchy for all objects is desirable or a more granular strategy should >> be taken. Related to that, should we expose all objects by default or just >> those that have certain properties? >> > > I'd expose only resources (either for configs or services) that are > configured on purpose to be exposed (having certain properties), using a > granular approach. > > Regards, > Tommaso > > >> >> Marius >> >> > -----Original Message----- >> > From: Carsten Ziegeler [mailto:[email protected]] >> > Sent: Tuesday, February 18, 2014 11:15 AM >> > To: [email protected] >> > Subject: Re: Replication REST-ful/HTTP API >> > >> > I prefer the granular design as well - and just to reiterate, the Sling >> concepts for >> > this are resource providers (and resource access security) >> > >> > Regards >> > Carsten >> > >> > >> > 2014-02-18 9:47 GMT+01:00 Tommaso Teofili <[email protected]>: >> > >> > > Does anyone else have any opinion and / or concerns? It'd be nice if >> > > we can move forward. >> > > >> > > Regards, >> > > Tommaso >> > > >> > > >> > > 2014-02-14 2:29 GMT+01:00 Alexander Klimetschek <[email protected]>: >> > > >> > > > On 13.02.2014, at 13:44, Tommaso Teofili <[email protected]> >> > > > wrote: >> > > > >> > > > > I personally prefer the granular one as it's more resource >> > > > > oriented, >> > > > which >> > > > > makes more sense in my opinion for an HTTP API (be it REST or not) >> > > > >> > > > Regarding REST: It is closer to REST only once you send out links to >> > > > the various options/commands. >> > > > >> > > > If the client needs to build the request itself and has to know URL >> > > > patterns or other headers or payload paths, it misses the hypermedia >> > > > constraint. >> > > > >> > > > So in itself, there is no real difference between granular and >> > > > flatten in the proposal: >> > > > >> > > > POST /system/replication/agent/{agentName}/replicate >> > > > >> > > > and >> > > > >> > > > POST /system/replication/all/replicate { "agents" : [ "publish1", >> > > > "publish2" ] // .... >> > > > } >> > > > >> > > > However, the granular one has the advantage that you can more easily >> > > > do the linking, for example using standard <form> and hrefs. >> > > > >> > > > Basically, if you can browse it with some simple HTML pages and do >> > > > everything (find all agents, look at agent state, clear queue, >> > > > import package etc.), then this is good. >> > > > >> > > > Just my 2 cents >> > > > Alex >> > > >> > >> > >> > >> > -- >> > Carsten Ziegeler >> > [email protected] >>
