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 <[email protected]> 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
