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 ;-)
