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.



[1] http://incubator.apache.org/sling/site/architecture.html

Reply via email to