The Future of Sling vs Microsling

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org