The Apache Sling project basically consists of three parts: the API, Sling and Microsling. The API defines the general system contracts and interfaces. Sling and Microsling are two implementations of the API; Microsling has been introduced initially as an educational tool to show how Sling works for processing requests. In addition Microsling served as a testbed for the evolution of the former Component API to the current Sling API.
It was always felt that microsling should stay, what it is: an educational tool, testbed and probably a very crude rapid development tool. It never was intended to become as powerful as Sling in terms of functionality, configurability and flexibility. While the latter two items clearly are not addressed by any recent microsling development, functionality tends to grow. At the same time we tried very hard to migrate Sling from the former Component API to the Sling API and we are almost there, except for some polishings (like separating out functionality of the sling/core project into separate projects and migration to using Java Scripting API). At this point in time, it seems questionable that we keep on working and extending two implementations of the Sling API more or less independantly and in parallel. Now, don't get me wrong, the introduction of Microsling was a very good thing (TM) and I really value all the effort that went into it - and in the end the whole Sling project benefitet from it. But now it seems to me that this split between Sling and Microsling will come with (more) problems in the future. Why? Well, we are not focusing on one framework but two. Selling a new framework to potential users will be hard these days. But selling a new framework that comes in two totally different flavours is much much harder - if not impossible. But that's just one reason. Inevitably, keeping two solutions will lead to confusion and problems over time. It will be very difficult to tell people the difference, to proof that one or the other is needed and makes sense. And obviously there is the very big challenge to keep them compatible. Sooner or later something will be introduced in one of the two which will be different in the other one. Latest discussions about initial content and other things clearly show this. I know that this is more or less theoretically here as we are not yet at the problematic point, but being realistic I strongly believe that this will happen. Even if we try to avoid such things. So why not focusing on one framework: Sling? What problems exist which make using Sling instead of Microsling impossible or unwantable? There is always the argument that Sling is too heavy because it's OSGi based. But well, honestly, OSGi is a very small framework, startup time is very fast (you don't even notice OSGi) and the additional memory consumption is very low. Developing bundles, and deploying, installing, updating or uninstalling them is very simple. This can be done by Maven, or you can use command line tools or a nice gui tool etc. So what else is either missing or inconvenient at the moment? I propose therefore to move Microsling back into the sandbox, fix the problems that will be mentioned in this thread and focus on the real stuff, the Apache Sling framework. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
