[RT] breaking Sling into smaller pieces?

[Bertrand Delacretaz <bd...@apache.org>]

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

Re: [RT] breaking Sling into smaller pieces?

[Juan José Vázquez Delgado <ju...@gmail.com>]

Hi all,

I´m absolutely agree with Bertrand´s proposal. I think the Sling´s success
depends of his goals staying delimited.

On the other hand, I like sling-jcr out of jcr-core, but I don´t know Sling
much as you.

BR,

Juanjo.

On 10/9/07, Bertrand Delacretaz <bd...@apache.org> 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
>

Re: [RT] breaking Sling into smaller pieces?

[Christophe Lombart <ch...@gmail.com>]

it sounds good but unfortunately I didn't find time to work on Sling.


On 10/9/07, Bertrand Delacretaz <bd...@apache.org> 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
>

Re: [RT] breaking Sling into smaller pieces?

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

David Nuescheler wrote:
> 
> I completely agree, but don't ever want to find myself in a in position
> arguing why sling easier to use than wicket or more extensible
> than spring. 
Yepp, that's a problem other well-known web frameworks face for the last
months (or years). The obvious solution (and tendency of most web
frameworks) is to be open and allow developers to assemble their
development environment by choosing several famous things, e.g.
combining Spring with JSF (or whatever).

With Sling we might hit the same problem, but so far we did imho the
right decision to use OSGi as an environment. In this environment you
can use other containers like Spring etc if you want to. And they will
work without problems with Sling. So the best thing we can do is to do
nothing in this area as this gives people freedom of choice :) (Yeah, I
can guess what someone will answer to this one...)

The same is true for the presentation layer. People should be able to
use JSPs, servlets or other frameworks if they want to. The focus of
Sling is not to create a presentation layer. Therefore we should try to
support those alternatives that make sense or are demanded.

All together, focusing on the content part is the right thing.


Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] breaking Sling into smaller pieces?

[David Nuescheler <da...@day.com>]

Hi guys,

> > For me sling has a very simple main purpose:
> > It is the JCR centric web application development
> > framework of my dreams.
> Yes, true, but ... "JCR-centric" is a very vague term in itself :-)
I agree that there are many flavours of how you could use
the a content repository, there should be a recommend way
though.

In my mind the initial message should be:
If you would like to build a webapp using a
content repository  ...use sling.

I think sling will be more successful providing "rails"
instead of "options", in a sense something like:

If you want to build a webapp using a content
repository, this is how you develop, deploy and
run it. (sling: osgi, rest, content packages, ...)

> > 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 do not completely agree here: There are multiple requirements for a
> web application framework: Extensibility, Manageability, Stability,
> Ease-of-Use, Data Persistence come to mind; certainly there are more.

I completely agree, but don't ever want to find myself in a in position
arguing why sling easier to use than wicket or more extensible
than spring. If someone ask me: "why should I use Sling?" then
my answer will always be "...because you believe that everything
is content."

> Now, Sling is probably not revolutionary with respect to a single
> requirement (except with regard to Data Persistencew) in that it is
> better to extend than framework X, better to manage than framework Y
> etc. All-in-all, when counting all parts together, you get a framework
> which is dramatically "better" than other frameworks in the field. And
> this is IMHO the real value of Sling.

I think I am in no position to judge the extensibility, stability or
manageability of other webframeworks, simply because I have
not used any of them long enough. ;)

However since perception is reality, I think we will never be able to
be (perceived as) more robust and extensible than spring or easier
to use than wicket or ror. So in my mind attempting to
differentiate along these lines is pointless...

Let me try to explain my view differently,
the most trafficked "Photo Managment Application"
on the net is facebooks. It lacks tons of features (until recently you
were not even able to sort photos), but it has its "secret sauce"
which is the "Social Graph". In my mind slings secret sauce is
the Content Repository.

> > I think putting the Content Repository at its core
> > certainly gives sling a very clear and easy to
> > express differentiator.
> This is what we do, except that we do not lock the Sling API into the
> JCR but say, a Sling application may depend on Sling providing the data
> to work with in a uniform fassion and that Sling applications do not
> have to care much about persistence issues. This is IMHO a big
> differentiator to most if not all frameworks around.
I think it is very common for web frameworks to abstract their
persistence. Amongst the ones that I can remember off the top
of my head only very few don't.

> Currently, Sling is of course locked into JCR, as the Content
> provisioning only supports JCR and authentication depends on and
> requires the JCR repository.
I agree and it sounds like nobody has a real-life usecase
to use something else really. It reminds me a bit of the argument
"Yes, SOAP could be sent using various transport protocols, but
in reality people only use http, and there really is no reason not
to use http ;)" ...so why the abstraction? I think abstraction or indirection
always come at a price.

regards,
david

Re: [RT] breaking Sling into smaller pieces?

[Felix Meschberger <fm...@gmail.com>]

Am Dienstag, den 09.10.2007, 16:35 +0200 schrieb David Nuescheler:
> For me sling has a very simple main purpose:
> It is the JCR centric web application development
> framework of my dreams.

Yes, true, but ... "JCR-centric" is a very vague term in itself :-)

> 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 do not completely agree here: There are multiple requirements for a
web application framework: Extensibility, Manageability, Stability,
Ease-of-Use, Data Persistence come to mind; certainly there are more.

Now, Sling is probably not revolutionary with respect to a single
requirement (except with regard to Data Persistencew) in that it is
better to extend than framework X, better to manage than framework Y
etc. All-in-all, when counting all parts together, you get a framework
which is dramatically "better" than other frameworks in the field. And
this is IMHO the real value of Sling.

> I think putting the Content Repository at its core
> certainly gives sling a very clear and easy to
> express differentiator.

This is what we do, except that we do not lock the Sling API into the
JCR but say, a Sling application may depend on Sling providing the data
to work with in a uniform fassion and that Sling applications do not
have to care much about persistence issues. This is IMHO a big
differentiator to most if not all frameworks around.

Currently, Sling is of course locked into JCR, as the Content
provisioning only supports JCR and authentication depends on and
requires the JCR repository.

Regards
Felix

Re: [RT] breaking Sling into smaller pieces?

[Bertrand Delacretaz <bd...@apache.org>]

On 10/9/07, David Nuescheler <da...@day.com> wrote:

> ...Of course I would personally but sling-jcr into sling-core
> but i think that's to be expected, considering my
> point of view ;)...

By sling-jcr I meant the "boring" stuff, wrappers and the like, which
would only clutter the core, as the aim would be to keep that core as
small as possible.

But I haven't looked at exactly what's in sling-jcr now, some of it
might need to be in the core.

-Bertrand

Re: [RT] breaking Sling into smaller pieces?

[David Nuescheler <da...@day.com>]

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

Re: [RT] breaking Sling into smaller pieces?

[Felix Meschberger <fm...@gmail.com>]

Hi all,

For completeness sake (Bertrand already noted this page in another
post): I put up a quick recount of the current state of the discussion
in our Wiki at http://cwiki.apache.org/SLING/sling-api-redesign.html.

Regards
Felix


Am Mittwoch, den 10.10.2007, 09:43 +0200 schrieb Bertrand Delacretaz:
> On 10/10/07, Felix Meschberger <fm...@gmail.com> wrote:
> > Am Dienstag, den 09.10.2007, 13:36 +0200 schrieb Bertrand Delacretaz:
> ...
> > > -Uses servlets or scripts to process the requests based on the HTTP
> > > uniform interface (get, post, put, delete).
> >
> > How is a resource represented ? I think having an abstraction between
> > the framework and the real data (be it an OCM mapped object or a JCR
> > node or a plain file or whatever) helps keeping the framework generic a
> > lot. Otherwise we would be supporting special cases right from the
> > start...
> 
> Maybe a Resource could be an interface with just a getURI()
> method...Sling itself might not care exactly what the Resource is,
> maybe only the user's code needs to know (for rendering, to select
> which Servlet to use, etc).
> 
> > ...Currently, the Sling API is completely agnostic of OSGi. The
> > implementation of the API, though, is not OSGi agnostic (of course), but
> > this is IMHO acceptable....
> 
> Cool - of course we'll take full advantage of OSGi at the
> implementation level, but making it possible for newbies to understand
> Sling without caring about OSGi might help.
> 
> > >... These tools could also be useful outside of Sling, but it is not our
> > > priority to make them standalone.
> >
> > Depends on how much they integrate with sling-core. I think it is more
> > the other way around: We should care to reuse as much as possible of
> > existing tools and just integrate them into sling.
> 
> ok, agreed.
> 
> > ...Providing a "glue" to Wicket and others come to mind here...
> 
> Now that'd be really cool!
> 
> > ...I fear, if we talk about modifying the handling of the resource (or
> > Content with OCM Mapping) as we have it today, there might be more to
> > do ...
> 
> Yes, I have not evaluated precisely how much work this needs. But it
> sounds like the right thing to do ;-)
> 
> -Bertrand

Re: [RT] breaking Sling into smaller pieces?

[Bertrand Delacretaz <bd...@apache.org>]

On 10/10/07, Felix Meschberger <fm...@gmail.com> wrote:
> Am Dienstag, den 09.10.2007, 13:36 +0200 schrieb Bertrand Delacretaz:
...
> > -Uses servlets or scripts to process the requests based on the HTTP
> > uniform interface (get, post, put, delete).
>
> How is a resource represented ? I think having an abstraction between
> the framework and the real data (be it an OCM mapped object or a JCR
> node or a plain file or whatever) helps keeping the framework generic a
> lot. Otherwise we would be supporting special cases right from the
> start...

Maybe a Resource could be an interface with just a getURI()
method...Sling itself might not care exactly what the Resource is,
maybe only the user's code needs to know (for rendering, to select
which Servlet to use, etc).

> ...Currently, the Sling API is completely agnostic of OSGi. The
> implementation of the API, though, is not OSGi agnostic (of course), but
> this is IMHO acceptable....

Cool - of course we'll take full advantage of OSGi at the
implementation level, but making it possible for newbies to understand
Sling without caring about OSGi might help.

> >... These tools could also be useful outside of Sling, but it is not our
> > priority to make them standalone.
>
> Depends on how much they integrate with sling-core. I think it is more
> the other way around: We should care to reuse as much as possible of
> existing tools and just integrate them into sling.

ok, agreed.

> ...Providing a "glue" to Wicket and others come to mind here...

Now that'd be really cool!

> ...I fear, if we talk about modifying the handling of the resource (or
> Content with OCM Mapping) as we have it today, there might be more to
> do ...

Yes, I have not evaluated precisely how much work this needs. But it
sounds like the right thing to do ;-)

-Bertrand

Re: [RT] breaking Sling into smaller pieces?

[Felix Meschberger <fm...@gmail.com>]

Am Dienstag, den 09.10.2007, 13:36 +0200 schrieb Bertrand Delacretaz: 
> 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).

How is a resource represented ? I think having an abstraction between
the framework and the real data (be it an OCM mapped object or a JCR
node or a plain file or whatever) helps keeping the framework generic a
lot. Otherwise we would be supporting special cases right from the
start.

Looking at it from this point of view, the Content interface is
certainly a starting point for such an abstraction. Whether the real
data is then provided as part of an implementation of the Content
interface or by a data provider using the Content object as an address
much like an URL is to be discussed.

> A simple example webapp allows developers to test this without
> spending more than 15 minutes to download, run and start exploring it.

Sounds good.

> 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.

Agreed. Currently, the Sling API is completely agnostic of OSGi. The
implementation of the API, though, is not OSGi agnostic (of course), but
this is IMHO acceptable.


> 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.

Depends on how much they integrate with sling-core. I think it is more
the other way around: We should care to reuse as much as possible of
existing tools and just integrate them into sling.

Providing a "glue" to Wicket and others come to mind here.

> 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.

Well, I tink, if we do not modify anything regarding the resolution of a
request to some piece of code to act upon the request, that is true. But
I fear, if we talk about modifying the handling of the resource (or
Content with OCM Mapping) as we have it today, there might be more to
do ...

Unless I completely misunderstand your thread, there is some changes
ahead.

Regards
Felix