You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Oliver Lietz <ap...@oliverlietz.de> on 2018/11/04 18:41:36 UTC
Capabilities
Hi *,
sorry if I do not get the point of Sling Capabilities, but wouldn't it make
sense to exploit OSGi Capabilities instead of building our own API and
implementation for capabilities?
https://osgi.org/specification/osgi.core/7.0.0/framework.resource.html
Regards,
O.
Re: Capabilities
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 21 November 2018 14:51:56 Carsten Ziegeler wrote:
> Ah ok, thanks
>
> Can't we use openapi for this?
No, I don't think OpenAPI does help here.
Regards,
O.
> Carsten
>
> Am 21.11.2018 um 11:06 schrieb Bertrand Delacretaz:
> > On Wed, Nov 21, 2018 at 10:58 AM Carsten Ziegeler <cz...@apache.org>
wrote:
> >> ...Sorry, I guess I missed the whole discussion, what are these
> >> capabilities about?...
> >
> > My first reply in this thread should explain that:
> >
> > https://lists.apache.org/thread.html/ddc3c78916531f1ff2c31439f1048c098c04c
> > f1173ceef3067958209@%3Cdev.sling.apache.org%3E
> >
> > -Bertrand
Re: Capabilities
Posted by Carsten Ziegeler <cz...@apache.org>.
Ah ok, thanks
Can't we use openapi for this?
Carsten
Am 21.11.2018 um 11:06 schrieb Bertrand Delacretaz:
> On Wed, Nov 21, 2018 at 10:58 AM Carsten Ziegeler <cz...@apache.org> wrote:
>> ...Sorry, I guess I missed the whole discussion, what are these
>> capabilities about?...
>
> My first reply in this thread should explain that:
>
> https://lists.apache.org/thread.html/ddc3c78916531f1ff2c31439f1048c098c04cf1173ceef3067958209@%3Cdev.sling.apache.org%3E
>
> -Bertrand
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Capabilities
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 21, 2018 at 10:58 AM Carsten Ziegeler <cz...@apache.org> wrote:
> ...Sorry, I guess I missed the whole discussion, what are these
> capabilities about?...
My first reply in this thread should explain that:
https://lists.apache.org/thread.html/ddc3c78916531f1ff2c31439f1048c098c04cf1173ceef3067958209@%3Cdev.sling.apache.org%3E
-Bertrand
Re: Capabilities
Posted by Carsten Ziegeler <cz...@apache.org>.
Sorry, I guess I missed the whole discussion, what are these
capabilities about?
Regards
Carsten
Am 20.11.2018 um 06:29 schrieb Oliver Lietz:
> On Monday 19 November 2018 16:26:13 Bertrand Delacretaz wrote:
>> Hi Oliver,
>
> Hi Bertrand,
>
> looping in Carsten, David and Karl to get their attention and hopefully OSGi
> PoV...
>
>> On Thu, Nov 8, 2018 at 10:51 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
>>> ...In my opinion we should make capabilities (e.g. similarity search)
>>> known to the OSGi Framework first....
>>>
>>> ...(I'm sure there is no HTTP interface to OSGi Capabilities yet).
>>
>> Ok, IIUC what you suggest is that all capabilities are made available
>> to the OSGi Resolver, and then our Sling Capabilities HTTP API is just
>> a way to query that.
>
> Right.
>
>> I think it makes sense in principle, but:
>>
>> a) Is it possible for things which are not bundles to contribute
>> capabilities dynamically to the OSGi Resolver? I think some of those
>> will depend on configuration values which activate features or not -
>> so not just static capabilities based on whether a specific module is
>> present.
>
> Currently it's only possible to provide capabilities via bundle manifest.
> We could easily create fragment bundles for dynamic capabilities with
> TinyBundles and attach them to the host bundle providing a capability.
>
> Created FELIX-5983 to expose capabilities and FELIX-5984 to allow registration
> of capabilities via API.
>
> https://issues.apache.org/jira/browse/FELIX-5983
> https://issues.apache.org/jira/browse/FELIX-5984
>
>> b) Our HTTP Capabilities API has to take access control into account.
>> OSGi capabilites are by default an admin/deployer thing and making
>> them available to non-admin Sling clients will break trust boundaries.
>
> ACK (this feature is independent of the capabilities source).
>
> Just curious, what's the usecase for non-admin clients?
>
>> I'm open to suggestions on how to solve these things, but if we don't
>> have simple answers to a) and b) I think the current structure will
>> also work, as it allows for providing CapabilitiesSource services that
>> expose OSGi capabilities with access control (once SLING-8120 is
>> implemented). The downside is that not all capabilities will be
>> available to the OSGi resolver, but if that doesn't support dynamic
>> capabilities there's no point in doing that - so let's see what people
>> think about a) and b)
>
> Regards,
> O.
>
>> -Bertrand
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Capabilities
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 19 November 2018 16:26:13 Bertrand Delacretaz wrote:
> Hi Oliver,
Hi Bertrand,
looping in Carsten, David and Karl to get their attention and hopefully OSGi
PoV...
> On Thu, Nov 8, 2018 at 10:51 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
> > ...In my opinion we should make capabilities (e.g. similarity search)
> > known to the OSGi Framework first....
> >
> > ...(I'm sure there is no HTTP interface to OSGi Capabilities yet).
>
> Ok, IIUC what you suggest is that all capabilities are made available
> to the OSGi Resolver, and then our Sling Capabilities HTTP API is just
> a way to query that.
Right.
> I think it makes sense in principle, but:
>
> a) Is it possible for things which are not bundles to contribute
> capabilities dynamically to the OSGi Resolver? I think some of those
> will depend on configuration values which activate features or not -
> so not just static capabilities based on whether a specific module is
> present.
Currently it's only possible to provide capabilities via bundle manifest.
We could easily create fragment bundles for dynamic capabilities with
TinyBundles and attach them to the host bundle providing a capability.
Created FELIX-5983 to expose capabilities and FELIX-5984 to allow registration
of capabilities via API.
https://issues.apache.org/jira/browse/FELIX-5983
https://issues.apache.org/jira/browse/FELIX-5984
> b) Our HTTP Capabilities API has to take access control into account.
> OSGi capabilites are by default an admin/deployer thing and making
> them available to non-admin Sling clients will break trust boundaries.
ACK (this feature is independent of the capabilities source).
Just curious, what's the usecase for non-admin clients?
> I'm open to suggestions on how to solve these things, but if we don't
> have simple answers to a) and b) I think the current structure will
> also work, as it allows for providing CapabilitiesSource services that
> expose OSGi capabilities with access control (once SLING-8120 is
> implemented). The downside is that not all capabilities will be
> available to the OSGi resolver, but if that doesn't support dynamic
> capabilities there's no point in doing that - so let's see what people
> think about a) and b)
Regards,
O.
> -Bertrand
Re: Capabilities
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Oliver,
On Thu, Nov 8, 2018 at 10:51 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
> ...In my opinion we should make capabilities (e.g. similarity search) known to
> the OSGi Framework first....
> ...(I'm sure there is no HTTP interface to OSGi Capabilities yet).
Ok, IIUC what you suggest is that all capabilities are made available
to the OSGi Resolver, and then our Sling Capabilities HTTP API is just
a way to query that.
I think it makes sense in principle, but:
a) Is it possible for things which are not bundles to contribute
capabilities dynamically to the OSGi Resolver? I think some of those
will depend on configuration values which activate features or not -
so not just static capabilities based on whether a specific module is
present.
b) Our HTTP Capabilities API has to take access control into account.
OSGi capabilites are by default an admin/deployer thing and making
them available to non-admin Sling clients will break trust boundaries.
I'm open to suggestions on how to solve these things, but if we don't
have simple answers to a) and b) I think the current structure will
also work, as it allows for providing CapabilitiesSource services that
expose OSGi capabilities with access control (once SLING-8120 is
implemented). The downside is that not all capabilities will be
available to the OSGi resolver, but if that doesn't support dynamic
capabilities there's no point in doing that - so let's see what people
think about a) and b)
-Bertrand
Re: Capabilities
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 05 November 2018 11:05:19 Bertrand Delacretaz wrote:
> Hi,
Hi Bertrand,
> On Sun, Nov 4, 2018 at 9:45 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
> > > > ...wouldn't it make sense to exploit OSGi Capabilities instead of
> > > > building our own API and implementation for capabilities?...
>
> The goal of the Capabilities module [1] is to provide a simple HTTP
> API that indicates what a Sling instance can do.
why should we limit ourselves by creating a Sling-specific API?
> I don't think the HTTP part of that is covered by OSGi capabilities,
> and [1] really just defines a JSON format for capabilities, a way to
> set up such endpoints with access control and a way to decide what's
> output (via CapabilitiesSource services).
>
> One can very much implement a CapabilitiesSource [2] that exposes
> relevant OSGi capabilities, would that work for you?
>
> Or do you mean that I should have used something from [3] instead of
> CapabilitiesSource?
In my opinion we should make capabilities (e.g. similarity search) known to
the OSGi Framework first. That would mean components et al. can depend on them
via requirements - much broader use.
The Resolver keeps track of the capabilities and we just have to find a way to
get and expose them (I'm sure there is no HTTP interface to Capabilities yet).
My proposal (Resolver = "Cap. Registry"):
Capabilities -> OSGi Framework <- Servlet HTTP/JSON
Capabilities -> OSGi Framework <- Requirements
Sling Capabilities and your proposal (CapabilitiesServlet = "Cap. Registry"):
CapabilitiesSources -> CapabilitiesServlet HTTP/JSON (Cap. Registry)
CapabilitiesSources -> Capabilities -> OSGi Framework <- Requirements
Is it understandable?
Regards,
O.
> -Bertrand
>
> [1] https://github.com/apache/sling-org-apache-sling-capabilities
> [2]
> https://github.com/apache/sling-org-apache-sling-capabilities/blob/master/s
> rc/main/java/org/apache/sling/capabilities/CapabilitiesSource.java [3]
> https://osgi.org/specification/osgi.core/7.0.0/framework.resource.html
Re: Capabilities
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sun, Nov 4, 2018 at 9:45 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
> > > ...wouldn't it make sense to exploit OSGi Capabilities instead of building our own API and
> > > implementation for capabilities?...
The goal of the Capabilities module [1] is to provide a simple HTTP
API that indicates what a Sling instance can do.
I don't think the HTTP part of that is covered by OSGi capabilities,
and [1] really just defines a JSON format for capabilities, a way to
set up such endpoints with access control and a way to decide what's
output (via CapabilitiesSource services).
One can very much implement a CapabilitiesSource [2] that exposes
relevant OSGi capabilities, would that work for you?
Or do you mean that I should have used something from [3] instead of
CapabilitiesSource?
-Bertrand
[1] https://github.com/apache/sling-org-apache-sling-capabilities
[2] https://github.com/apache/sling-org-apache-sling-capabilities/blob/master/src/main/java/org/apache/sling/capabilities/CapabilitiesSource.java
[3] https://osgi.org/specification/osgi.core/7.0.0/framework.resource.html
Re: Capabilities
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Sunday 04 November 2018 20:09:55 David Bosschaert wrote:
> Hi Oliver,
Hi David,
> For those who don't know which Sling Capabilities you mean it would be
> helpful to include a link to the relevant source.
https://github.com/apache/sling-org-apache-sling-capabilities
(currently under vote)
HTH,
O.
> Best regards,
>
> David
>
> On Sun, 4 Nov 2018 at 18:41, Oliver Lietz <ap...@oliverlietz.de> wrote:
> > Hi *,
> >
> > sorry if I do not get the point of Sling Capabilities, but wouldn't it
> > make
> > sense to exploit OSGi Capabilities instead of building our own API and
> > implementation for capabilities?
> >
> > https://osgi.org/specification/osgi.core/7.0.0/framework.resource.html
> >
> > Regards,
> > O.
Re: Capabilities
Posted by David Bosschaert <da...@gmail.com>.
Hi Oliver,
For those who don't know which Sling Capabilities you mean it would be
helpful to include a link to the relevant source.
Best regards,
David
On Sun, 4 Nov 2018 at 18:41, Oliver Lietz <ap...@oliverlietz.de> wrote:
> Hi *,
>
> sorry if I do not get the point of Sling Capabilities, but wouldn't it
> make
> sense to exploit OSGi Capabilities instead of building our own API and
> implementation for capabilities?
>
> https://osgi.org/specification/osgi.core/7.0.0/framework.resource.html
>
> Regards,
> O.
>
>
Re: Capabilities
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
FWIW, I needed a release of the capabilities modules in their present
state, just started the vote for capabilities and capabilities JCR
0.1.2
I'm not opposed to making changes based on concrete proposals though -
open to discussion.
-Bertrand