Hi Oliver, On Thu, Nov 8, 2018 at 10:51 PM Oliver Lietz <apa...@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
