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