Hi all, I finally somewhat finished the prototype [1] implementation of the "Everything is a Resource" concept and updated the wiki page. The prototype is not 100% complete yet - Filter support and Resource Events are not implemented yet - but I think it nicely shows where I wanted to be heading.
In particular it is now possible to directly address scripts (and servlets) to call them without requiring a node to be existing in the repository just to have a hook. In addition, OCM mapping is supported through the Adapter framework thus being able to split OCM mapping and resource resolution. Of course I think, the concept and implementation is worth it. Therefore, I would like to merge this into the trunk sometime next week, unless there are objections. Regards Felix [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/fmeschbe/resource Am Samstag, den 29.12.2007, 20:51 +0100 schrieb Felix Meschberger: > Hi all, > > After the recent thread on scripting "everything" and some off-line > discussions around this matter, I come to the conclusion, that it is > about time to introduce the Sling Paradigm: > > Everything is a Resource > > If Sling would be enhanced to make the ResourceResolver more flexibel > and powerful by the addition of ResourceProvider instances to define a > virtual resource tree accessible (and iterable) through the > ResourceResolver, we can make Sling much more scriptable than it is > today. > > The idea is to make servlets and filters registered as OSGi services > available through the ResourceResolver just like normal scripts. The > ServletResolver and Filter handlers could then just ask the > ResourceResolver for resources and adaptTo(Servlet.class) and > adaptTo(Filter.class), resp. Calling scripts from other scripts would > also be available through resolving the script Resource through the > ResourceResolver and adaptTo(SlingScript.class). > > Thus we drop the ScriptResolver, while the SerlvetResolver mainly > remains for Sling to be able to handle requests. > > Of course the adaptor mechanism must be enhanced to make it extensible. > I propose the definition of a Adaptable interface defining the > adaptTo(Class) method and an AdapterFactory mechanism providing easy > extensibility. This is built after the Eclipse PlatformObject, > IAdapterManager and IAdapterFactory but leverages the OSGi service > registry instead of the Eclipse Plugin mechanism. > > I wrote up a wiki page on this concept at [1]. > > Comments are welcome. I will try to set up a first prototype in the > whiteboard in the next few days. > > Regards > Felix > > [1] http://cwiki.apache.org/SLING/everything-is-a-resource.html
