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]
>
