atom feed16 messages in org.apache.incubator.sling-devRe: [RT] Shall we merge microsling in...
FromSent OnAttachments
Bertrand DelacretazDec 17, 2007 1:33 am 
Carsten ZiegelerDec 17, 2007 1:54 am 
Torgeir VeimoDec 17, 2007 1:55 am 
Bertrand DelacretazDec 17, 2007 2:03 am 
Torgeir VeimoDec 17, 2007 2:14 am 
Karl PaulsDec 17, 2007 2:21 am 
Carsten ZiegelerDec 17, 2007 2:21 am 
pi...@wasabicowboy.comDec 17, 2007 8:34 am 
Felix MeschbergerDec 17, 2007 3:02 pm 
Padraic HannonDec 17, 2007 3:09 pm 
Felix MeschbergerDec 17, 2007 3:24 pm 
pi...@wasabicowboy.comDec 17, 2007 5:32 pm 
Bertrand DelacretazDec 18, 2007 5:03 am 
Bertrand DelacretazDec 18, 2007 5:07 am 
Felix MeschbergerDec 18, 2007 5:19 am 
Bertrand DelacretazDec 18, 2007 5:55 am 
Subject:Re: [RT] Shall we merge microsling into Sling?
From:Felix Meschberger (fmes@gmail.com)
Date:Dec 17, 2007 3:24:23 pm
List:org.apache.incubator.sling-dev

Probably not quite. If we intend microsling to be an entry level Sling, we have to make sure, that every script and content used in microsling may still be used in Sling. Therefore, I rather see microsling as a pre-canned (stripped-down) Sling.

For example: Sling has a Configuration Admin Service and the Sling console. microsling will contain neither of both (out of the box). Actual extensibility of this stripped-down microsling may be documented somewhere, but would be of no issue to users of microsling.

We should not forget one thing: microsling is a single project containing (almost) anything, where as Sling (and the new microsling or minisling or whatever) will also be built out of multiple projects. I don't think this is an issues because when we can launch the new microsling easily, the internals are not really important as long as we can connect with WebDAV and simply add scripts and data....

Regards Felix

Am Montag, den 17.12.2007, 15:10 -0800 schrieb Padraic Hannon:

So for a microsling application project one would just use a different configuration for the DefaultServlet? Could this be handled via resource types? Using something like a microsling base node type for application resources (this just popped into my head and could be silly)? Integrating WebDAV as a bundle would be nice to have in general, all in all this sounds like a nice direction that would simplify explaining what is going on and allow for a more focused development effort as it seems that people tend to work on sling or microsling then they are faced with porting that into the other project.

-paddy

On Dec 17, 2007, at 3:02 PM, Felix Meschberger wrote:

Hi,

Agreed. About the only two differences I actually see between Sling and microsling are:

* Full-Blown and powerfull DefaultServlet (ujax amongst other things) * very simple setup/startup

The first issue may probably easily be "ported" to Sling in a separate DefaultServelt project. The basis for a flexible DefaultServlet is provided by ServletResolver of the sling/core project.

The second issue is actually not really a big one: The launcher folder contains two projects app and webapp. The app project is a project setup to launch Sling from the command line. This may easily be extended to include all required bundles to run Sling (or a minimal subset).

The launcher/webapp project is just an extension of the launcher/app project wrapping it in a web application archive instead of a standalone application. I think, for a quick 15minutes test, a standalone java application packed in a single exectuable JAR file is much easier to use than a web application ...

So, basically, all is there in Sling to build such a thing.

... The only thing missing is WebDAV: I think, if we could integrate this also as a Bundle, we could have a single application jar file being able to launch Sling with a repo and WebDAV and initial content if requireed etc.

WDYT ?

Regards Felix

Am Montag, den 17.12.2007, 10:33 +0100 schrieb Bertrand Delacretaz:

Hi,

I think microsling is now ready to become just a specific configuration of Sling.

That would save us the extra work (and potential community fragmentation) (and user indecision) (and fuzzy "marketing" message) that comes with having two similar-but-still-different codebases.

I'm pretty sure we can graft the microsling stuff on Sling as a set of OSGi bundles, without requiring any OSGi knowledge from beginners, and keep microsling's ease of use, all of microsling's current features, and the "testable in 15 minutes from scratch" requirement.

Empowering users to jump from simple microsling scripted stuff to full-blown OSGi-based java modules, within the same framework and webapp, sounds quite exciting to me.

WDYT?

-Bertrand, operating in Monday Morning's Wild Thinking Mode ;-)