Am Montag, den 08.10.2007, 12:08 +0200 schrieb Bertrand Delacretaz: > Yes, so my proposal is not much different to what we have now, except > that, as we see below, Content and Servlets are more decoupled from > JCR, mostly by using URIs instead of paths.
I like this (further) decoupling. This is what I tried to accomplish by factoring the ContentManager (no JCR referencees) out of the JcrContentManager (uses JCR). > Exactly, the Resource would only have an URL that points to it. > > > ...Not sure what you mean by "custom protocol handler": is this something > > we would have to define an API for or are you referring to the > > URLStreamHandler interface ?... > > I'm not sure if URLStreamHandler is enough. Cocoon does similar things > using the Excalibur source resolver mechanism, see > http://excalibur.apache.org/sourceresolve/index.html > > Having something similar (or reusing that code) in Sling might help a > lot in decoupling the resource processing from the actual resources > and their data sources. I looked at the Excalibur resolver. This sure lookes very interesting. Yet, I have some missing links: (1) The Excalibur Source provides access to file-like data, where the intent of our Content was to access mainly "structured" data in terms of properties and child objects with properties. (2) The Excalibur Source is intelligent in the sense, that it may implement additional interfaces like Modifiable, Traversable, ... Trying to map this on our ContentResolver and Content, I would probably get something like this: * A request URL (e.g. http://xy.com/some/index.html) is resolved to some Resource URL (e.g. jcr:/some/index). * The Resource URL is resolved to a Resource instance providing operative API comparable to the API provided by the Excalibur MovableSource, ModifiableSource, ... * The Resource provides a method getContent() returning the "mapped" Content - in case of JCR this might be Jackrabbit OCM mapped, in case of a filesystem File this might be an XML DOM or a loaded Properties object (depending on the MIME-type). What would then be the consequences for the Sling API ? Of course there is no single ContentManager but comparable to Excalibur something like ResourceResolver (mapping scheme to ResourceFactory), ResourceFactory and Resource. > In the simple case (which is probably all we need now), the Servlet > URI would be an OSGi service URI, for example > osgi-service:/<serviceName> as you suggest. or even osgi-service:<ldapfilter> where ldap filter would be a filter for BundleContext.getServiceReference(String clazz, String filter) - to simplify matters a default might be just a class name if the filter expression does not start with a "(". > ... Regards Felix
