Hi all, I think it is a great idea to come up with a rock-solid architecture diagram on how things work and breaking sling up into different larger pieces is certainly a good idea.
For me sling has a very simple main purpose: It is the JCR centric web application development framework of my dreams. This is the main differentiator for me. In my mind differentiators have to be simple. I think being more osgi than web framework A or more restful than framework B does not really justify slings existence. I think it is crucial for the success of sling to be able to argue why it is different, not so much why it is incrementally better. I think putting the Content Repository at its core certainly gives sling a very clear and easy to express differentiator. I am very much in agreement with Bertrand split-up. Of course I would personally but sling-jcr into sling-core but i think that's to be expected, considering my point of view ;) regards, david On 10/9/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Hi Sling team, > > (hmmm...long read ahead, sorry about that but I tried to keep it pragmatic ;-) > > When talking about Sling to people who don't know it, a reaction that > comes up very often is "this stuff looks cool, but I cannot really > figure out what it does". > > Looking at the list of bundles [1], I think breaking up Sling in > smaller pieces might help a lot, by allowing people to focus on what's > important for them. > > - o - > > I suggest the following parts: > > 1) Scriptable JCR-based REST resource processing framework (sling-core-*) > This is the clear focus of the project, other modules are only here to > support it. > > This module: > -Maps incoming HTTP requests to resources (JCR nodes or OCM-mapped objects) > -Uses servlets or scripts to process the requests based on the HTTP > uniform interface (get, post, put, delete). > > A simple example webapp allows developers to test this without > spending more than 15 minutes to download, run and start exploring it. > > This is usually the only module that web developers need to learn. > > If possible, the API of this module is independent of OSGi, but that's > not a priority. > > > 2) OSGI console and utilities (sling-osgi-*) > This can be useful outside of Sling, but it is not our priority to > make it standalone. > > > 3) Scripting tools (sling-scripting-*) > JSP compiler, future interfaces to other scripting engines, etc. > > These tools could also be useful outside of Sling, but it is not our > priority to make them standalone. > > > 4) JCR tools (sling-jcr-*) > Glue code for interaction between Sling and JCR repositories. > > - o - > > Users of the Sling core usually do not need to understand how 2), 3) > and 4) work. > > For modules 2) and 3) and 4), we try to reuse stuff from other > projects, as much as possible, or contribute stuff to other projects > so that they fit our needs. > > - o - > > If we agree on this, the next step might be to reorganize our code > base, with those four Maven modules at the top (sling-core, > sling-osgi, sling-scripting and sling-jcr), and sub-modules below > them. This entails little or no changes to existing code, just moving > modules around and renaming some of them to use their parent module's > name as a prefix. > > WDYT? > > -Bertrand > > > [1] http://incubator.apache.org/sling/site/architecture.html >
