Re: From Component API to Sling API (was: Simplifying our component api)

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

Am Montag, den 08.10.2007, 08:58 +0200 schrieb Bertrand Delacretaz:
> I *think* the model below more or less matches the current resource
> processing model, but makes it a bit more general and less dependent
> on JCR. Making it more generic and more plainly REST-oriented might
> help drive Sling acceptance, what do you think?

Definitely a good idea. I am not sure, I completely understand. See
below.

> ** The Sling request processing module (RPM) **
> 
> The RPM helps manage Resources in a REST way, using java code or
> scripted request processors.
> 
> As HTTP Requests come in, they are pre-processed by a series of
> ServletFilters, to select the Resource to process, find out more about
> the client browser and locale, etc.
> 
> The ResourceResolver filter selects the Resource that the current
> request applies to.

This is currently called the ContentResolver and a Resource is currently
called Content manifested by an implementation of the Content interface,
right ?

> The Resource is represented by an URL, using custom procotol handlers
> to map to the actual resource providers (for example,
> jcr:/default/content/mypage to point to a JCR repository resource).

Sounds interesting. So a Resource (aka Content) does not only have a
path but an URL, which might as well be file://... for filesystem based
resources ? Very nice in fact.

Not sure what you mean by "custom protocol handler": is this something
we would have to define an API for or are you referring to the
URLStreamHandler interface ?

> The ServletResolver selects the HttpServlet that will be used to
> process the Resource, and maps the Resource to a base (resource) path
> under which scripts can be found to process the request.

Yes, this task is currently not manifested by a named interface but
implemented by an internal class named ComponentResolverFilter. This
filter yields a Servlet (aka Component) for the Resource (aka Content).

Currently Components are registered OSGi services which are selected by
name. How would you envision resolution of Servlets from the Resources ?
Would the Content.getComponentId be replaced by something which returns
an URI to be interpreted in the context of the used scheme, such as
jcr:, file:, oder osgi-service: ?

Thinking about it, this seems interesting as for example, the
DefaultContent class currently returns the primary node type as its
Component ID (if not overwritten). It could return
jcr:/types/<node-type> which could be handled by the JCR handler to find
a Resource which actually is a Servlet ?? Other resources might use
osgi-service:<serviceName> and allow the OSGi service handler to select
a registered Servlet service ?

And then the jcr:/types/<node-type> resource may either be another
"descriptor" like today's ScriptedComponent or it may actually be a JSP
script or the root under which the JSP script would be found ? Would
then this JSP script or JSP selector script root have to be of a certain
node type ?

> Like Resources, Scripts are found and loaded using URLs and custom
> protocol handlers.
> 
> The default SlingHttpServlet looks for a request processing script
> based on HTTP uniform interface names, like "get.jsp", "post.jsp" or
> "put.rb" or "delete.js", using a configurable order of possible script
> file extensions which map to script interpreters.

So, in fact the SlingHttpServlet would be much like today's
ScriptedComponent of the scripting-core bundle ?

I like the enhancement of using such uniform names based on the HTTP
method. Would there be some fallback mechanism, say e.g. if there is no
post.* method for a POST request, we would take a get.* ?


> 
> This processing chain is built from OSGi bundles, to make each of its
> elements easy to implement, test and replace.
> 
> -Bertrand

Re: From Component API to Sling API (was: Simplifying our component api)

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

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

> ...I think generally I would be cautious about introducing too much abstraction.
>
> In many respects unnecessary abstraction causes software to fail in the market.
> I agree with Stefano 100% on this one ...

Ok - I see your point, taking full advantage of JCR instead of trying
to hide it might be more helpful.

But note that the current OCM is an abstraction on top of JCR, we
might want to make its use optional and allow people to use "raw" JCR
Nodes in their Sling apps.

> ...Some more thoughts on choices and flexibility of Joel on that:
> http://www.joelonsoftware.com/items/2006/11/21.html...

Totally agreed, I remember reading that one a while ago. And the
"paradox of choice" book is also on my bookshelf, a very good read.

So at this point, what's left of my ideas about Sling request processing are

a) Make the Sling request processing module as small and
understandable as possible, clearly separated from the rest (I'll
start another "breaking Sling into smaller pieces" thread)

b) Make the REST ideas of the Sling request processing module more obvious

c) Allow people to use JCR nodes directly if they don't want the OCM stuff

-Bertrand

Re: From Component API to Sling API (was: Simplifying our component api)

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

Hi all,

> Am Montag, den 08.10.2007, 12:08 +0200 schrieb Bertrand Delacretaz:
> > Yes, so my proposal is not much different to what we have now, except
> > that, as we see below, Content and Servlets are more decoupled from
> > JCR, mostly by using URIs instead of paths.
>
> I like this (further) decoupling.

I think generally I would be cautious about introducing too much abstraction.

In many respects unnecessary abstraction causes software to fail in the market.
I agree with Stefano 100% on this one ...

---
http://www.betaversion.org/~stefano/papers/ac2006.2.pdf
see slide 145 and following (I am not kidding...;) )
---

... which he calls "Flexibility syndrome" or "yagni".

I think one of the reasons why Hibernate was more successful than JDO or
EJB is really because it clearly always focussed on an RDBMS as the backing
store, which made its purpose very simple and clear and allowed for
a lot of optimizations that made sense for that one persistence layer.

I believe see that leaving out the right features and extension points
is the real art of software design and development, which in
my mind shows particularly well in Apple vs. MS applications ;)

Some more thoughts on choices and flexibility of Joel on that:
http://www.joelonsoftware.com/items/2006/11/21.html

Bottom-line (and small-surprise-tm): I do not mind strong ties
between Sling and JCR.

I think we should address all the possible things that people
could possibly use Sling for beyond JCR, once we are confronted
with real-life usecases.
(in Stefano speak: "scratch your own itch!")

regards,
david

Re: From Component API to Sling API

[Karl Pauls <ka...@gmail.com>]

On 10/13/07, Felix Meschberger <fm...@gmail.com> wrote:
> Am Donnerstag, den 11.10.2007, 22:10 +0200 schrieb Tobias Bocanegra:
> > > Therefore we always had the dream in Cocoon to use plain java.net
> > > classes to access any resource. In the last weeks I developed the
> > > excalibur jnet package which hopefully makes this dream come true in the
> > > near future. It is a package which is able to install own url handlers
> > > in a webapp environment and which is able to make source implementations
> > > available through java.net.URL class. The idea is to use well known api
> > > and classes to access custom stuff. Even for the XML streaming stuff, I
> > > created a prototype which (ab)uses the getContent(Class[]) method.
> >
> > i have some concerns if the java.net.URL stream handler works well
> > with the OSGI framework since the handlers/factory is a static field
> > in the URL class. i just remember some visibility issues.
>
> Well actually, the OSGi core spec is well aware of the restrictions of
> the java.net.URL class allowing specifying the URLStreamHandlerFactory
> only once in a lifetime (of the VM). And therefore, there is a spec
> enabling bundles to register (and unregister) URLStreamHandlerFactories
> at will. Felix contains some basic implementation, which fails under
> certain circumstances, a first enhanced implementation of mine has not
> been used due to uncertainties regarding licensing (the implementation
> was developped looking very closely at the Eclipse implementation)...
>
> So implementing URLStreamHandlerFactories in an OSGi environment is not
> that big an issue as it is usually.

Well, this depends on whether you assume a Sun JDK or not. The main
issue is that we need to use reflection to replace the standard url
connection lookup stuff with ours if it has been set already. This
obviously depends on the JDK implementation.

regards,

Karl

> But I agree with Roys remark of java.net.URL. If find it way to heavy,
> so using just a string for URI or the URI class (which just operates on
> a string level) might be a better way to go.
>
> Regards
> Felix
>
> Regards
> Felix
>
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: From Component API to Sling API

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

Am Donnerstag, den 11.10.2007, 22:10 +0200 schrieb Tobias Bocanegra:
> > Therefore we always had the dream in Cocoon to use plain java.net
> > classes to access any resource. In the last weeks I developed the
> > excalibur jnet package which hopefully makes this dream come true in the
> > near future. It is a package which is able to install own url handlers
> > in a webapp environment and which is able to make source implementations
> > available through java.net.URL class. The idea is to use well known api
> > and classes to access custom stuff. Even for the XML streaming stuff, I
> > created a prototype which (ab)uses the getContent(Class[]) method.
> 
> i have some concerns if the java.net.URL stream handler works well
> with the OSGI framework since the handlers/factory is a static field
> in the URL class. i just remember some visibility issues.

Well actually, the OSGi core spec is well aware of the restrictions of
the java.net.URL class allowing specifying the URLStreamHandlerFactory
only once in a lifetime (of the VM). And therefore, there is a spec
enabling bundles to register (and unregister) URLStreamHandlerFactories
at will. Felix contains some basic implementation, which fails under
certain circumstances, a first enhanced implementation of mine has not
been used due to uncertainties regarding licensing (the implementation
was developped looking very closely at the Eclipse implementation)...

So implementing URLStreamHandlerFactories in an OSGi environment is not
that big an issue as it is usually.

But I agree with Roys remark of java.net.URL. If find it way to heavy,
so using just a string for URI or the URI class (which just operates on
a string level) might be a better way to go.

Regards
Felix

Regards
Felix

Re: From Component API to Sling API

[Tobias Bocanegra <to...@day.com>]

> Therefore we always had the dream in Cocoon to use plain java.net
> classes to access any resource. In the last weeks I developed the
> excalibur jnet package which hopefully makes this dream come true in the
> near future. It is a package which is able to install own url handlers
> in a webapp environment and which is able to make source implementations
> available through java.net.URL class. The idea is to use well known api
> and classes to access custom stuff. Even for the XML streaming stuff, I
> created a prototype which (ab)uses the getContent(Class[]) method.

i have some concerns if the java.net.URL stream handler works well
with the OSGI framework since the handlers/factory is a static field
in the URL class. i just remember some visibility issues.

reciting davids concerns - the main feature of sling is jcr - so i see
no need for other stream handlers.

regards, toby
-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Re: From Component API to Sling API

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

Roy T. Fielding wrote:
> On Oct 11, 2007, at 6:56 AM, Carsten Ziegeler wrote:
>> Now, all this sounds very cool and indeed it is - but users always had
>> the problem that they had to use the source resolver instead of plain
>> java.net.url classes. So before getting content you needed to get a
>> source resolver first. If you know how to do this, its really easy, but
>> if not it is painfull.
>>
>> Therefore we always had the dream in Cocoon to use plain java.net
>> classes to access any resource. In the last weeks I developed the
>> excalibur jnet package which hopefully makes this dream come true in the
>> near future. It is a package which is able to install own url handlers
>> in a webapp environment and which is able to make source implementations
>> available through java.net.URL class. The idea is to use well known api
>> and classes to access custom stuff. Even for the XML streaming stuff, I
>> created a prototype which (ab)uses the getContent(Class[]) method.
> 
> I don't think that is a good idea.  java.net.URL is infamous for
> being the worst web API on the planet -- it scrambled the concept
> of a simple federated identifier (data) into what is basically the
> HTTP interface (without actually knowing HTTP).  Most web apps
> that used it had to be completely rearchitected because the API
> interferes with sensible design.
> 
> A good web API is going to look a lot like an HTTP server, with
> connection handling being managed below message handling, which in
> turn is below URI mapping to resources, and finally mapping of
> HTTP method to actions on the resource.  I think we should avoid
> the standard Java APIs like the plague.
> 
Hmm, I'm not 100% sure but I think we are talking about different things
here. I guess you're refering to the "general" Sling API - and there I
agree with you that we should create something that fits natural with
the things it deals with.

I'm just talking about accessing stuff internally, like how do I read a
file etc. I think for this stuff, the java API is sufficient and works.
If we base on that, it provides also a seamless integration into other
frameworks as they are usually using the java api directly as well.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: From Component API to Sling API

["Roy T. Fielding" <fi...@gbiv.com>]

On Oct 11, 2007, at 6:56 AM, Carsten Ziegeler wrote:
> Now, all this sounds very cool and indeed it is - but users always had
> the problem that they had to use the source resolver instead of plain
> java.net.url classes. So before getting content you needed to get a
> source resolver first. If you know how to do this, its really easy,  
> but
> if not it is painfull.
>
> Therefore we always had the dream in Cocoon to use plain java.net
> classes to access any resource. In the last weeks I developed the
> excalibur jnet package which hopefully makes this dream come true  
> in the
> near future. It is a package which is able to install own url handlers
> in a webapp environment and which is able to make source  
> implementations
> available through java.net.URL class. The idea is to use well known  
> api
> and classes to access custom stuff. Even for the XML streaming  
> stuff, I
> created a prototype which (ab)uses the getContent(Class[]) method.

I don't think that is a good idea.  java.net.URL is infamous for
being the worst web API on the planet -- it scrambled the concept
of a simple federated identifier (data) into what is basically the
HTTP interface (without actually knowing HTTP).  Most web apps
that used it had to be completely rearchitected because the API
interferes with sensible design.

A good web API is going to look a lot like an HTTP server, with
connection handling being managed below message handling, which in
turn is below URI mapping to resources, and finally mapping of
HTTP method to actions on the resource.  I think we should avoid
the standard Java APIs like the plague.

....Roy

Re: From Component API to Sling API

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

Felix Meschberger wrote:
> 
> I looked at the Excalibur resolver. This sure lookes very interesting. Yet, I have some missing links:
> 
> (1) The Excalibur Source provides access to file-like data, where the
> intent of our Content was to access mainly "structured" data in terms of
> properties and child objects with properties.
> 
> (2) The Excalibur Source is intelligent in the sense, that it may
> implement additional interfaces like Modifiable, Traversable, ...
> 
> Trying to map this on our ContentResolver and Content, I would probably
> get something like this:
> 
> * A request URL (e.g. http://xy.com/some/index.html) is resolved to some
> Resource URL (e.g. jcr:/some/index).
> * The Resource URL is resolved to a Resource instance providing
> operative API comparable to the API provided by the Excalibur
> MovableSource, ModifiableSource, ...
> * The Resource provides a method getContent() returning the "mapped"
> Content - in case of JCR this might be Jackrabbit OCM mapped, in case of
> a filesystem File this might be an XML DOM or a loaded Properties object
> (depending on the MIME-type).
> 
> What would then be the consequences for the Sling API ? Of course there
> is no single ContentManager but comparable to Excalibur something like
> ResourceResolver (mapping scheme to ResourceFactory), ResourceFactory
> and Resource.
> 
Hmm, I haven't thought about this yet, but I would like to give some
more information about the excalibur stuff first :)

The excalibur sourceresolver is one of the greatest components I ever
saw as it provides a uniform way to access different data sources.
Everything is identified by a url. This component is key of Cocoon and
and is one of the reasons why Cocoon is so flexible. There are some
additions to the sourceresolver stuff for Cocoon, e.g. if a source is
able to stream its content as XML it implements another interface
(XMLizable from excalibur xmlutils) and the xml can be directly streamed
using sax events.

Now, all this sounds very cool and indeed it is - but users always had
the problem that they had to use the source resolver instead of plain
java.net.url classes. So before getting content you needed to get a
source resolver first. If you know how to do this, its really easy, but
if not it is painfull.

Therefore we always had the dream in Cocoon to use plain java.net
classes to access any resource. In the last weeks I developed the
excalibur jnet package which hopefully makes this dream come true in the
near future. It is a package which is able to install own url handlers
in a webapp environment and which is able to make source implementations
available through java.net.URL class. The idea is to use well known api
and classes to access custom stuff. Even for the XML streaming stuff, I
created a prototype which (ab)uses the getContent(Class[]) method.

So, to keep this long story short, we should try to use existing api if
it makes sense instead of creating new interfaces for things that
already exist.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: From Component API to Sling API (was: Simplifying our component api)

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

Am Montag, den 08.10.2007, 12:08 +0200 schrieb Bertrand Delacretaz:
> Yes, so my proposal is not much different to what we have now, except
> that, as we see below, Content and Servlets are more decoupled from
> JCR, mostly by using URIs instead of paths.

I like this (further) decoupling. This is what I tried to accomplish by
factoring the ContentManager (no JCR referencees) out of the
JcrContentManager (uses JCR).

> Exactly, the Resource would only have an URL that points to it.
> 
> > ...Not sure what you mean by "custom protocol handler": is this something
> > we would have to define an API for or are you referring to the
> > URLStreamHandler interface ?...
> 
> I'm not sure if URLStreamHandler is enough. Cocoon does similar things
> using the Excalibur source resolver mechanism, see
> http://excalibur.apache.org/sourceresolve/index.html
> 
> Having something similar (or reusing that code) in Sling might help a
> lot in decoupling the resource processing from the actual resources
> and their data sources.

I looked at the Excalibur resolver. This sure lookes very interesting. Yet, I have some missing links:

(1) The Excalibur Source provides access to file-like data, where the
intent of our Content was to access mainly "structured" data in terms of
properties and child objects with properties.

(2) The Excalibur Source is intelligent in the sense, that it may
implement additional interfaces like Modifiable, Traversable, ...

Trying to map this on our ContentResolver and Content, I would probably
get something like this:

* A request URL (e.g. http://xy.com/some/index.html) is resolved to some
Resource URL (e.g. jcr:/some/index).
* The Resource URL is resolved to a Resource instance providing
operative API comparable to the API provided by the Excalibur
MovableSource, ModifiableSource, ...
* The Resource provides a method getContent() returning the "mapped"
Content - in case of JCR this might be Jackrabbit OCM mapped, in case of
a filesystem File this might be an XML DOM or a loaded Properties object
(depending on the MIME-type).

What would then be the consequences for the Sling API ? Of course there
is no single ContentManager but comparable to Excalibur something like
ResourceResolver (mapping scheme to ResourceFactory), ResourceFactory
and Resource.

> In the simple case (which is probably all we need now), the Servlet
> URI would be an OSGi service URI, for example
> osgi-service:/<serviceName> as you suggest.

or even osgi-service:<ldapfilter>

where ldap filter would be a filter for
BundleContext.getServiceReference(String clazz, String filter) - to
simplify matters a default might be just a class name if the filter
expression does not start with a "(".

> ...

Regards
Felix

Re: From Component API to Sling API (was: Simplifying our component api)

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

On 10/8/07, Felix Meschberger <fm...@gmail.com> wrote:

> >... The ResourceResolver filter selects the Resource that the current
> > request applies to.
>
> This is currently called the ContentResolver and a Resource is currently
> called Content manifested by an implementation of the Content interface,
> right ?

Yes, so my proposal is not much different to what we have now, except
that, as we see below, Content and Servlets are more decoupled from
JCR, mostly by using URIs instead of paths.

>
> > The Resource is represented by an URL, using custom procotol handlers
> > to map to the actual resource providers (for example,
> > jcr:/default/content/mypage to point to a JCR repository resource).
>
> Sounds interesting. So a Resource (aka Content) does not only have a
> path but an URL, which might as well be file://... for filesystem based
> resources ? Very nice in fact....

Exactly, the Resource would only have an URL that points to it.

> ...Not sure what you mean by "custom protocol handler": is this something
> we would have to define an API for or are you referring to the
> URLStreamHandler interface ?...

I'm not sure if URLStreamHandler is enough. Cocoon does similar things
using the Excalibur source resolver mechanism, see
http://excalibur.apache.org/sourceresolve/index.html

Having something similar (or reusing that code) in Sling might help a
lot in decoupling the resource processing from the actual resources
and their data sources.

> ...Currently Components are registered OSGi services which are selected by
> name. How would you envision resolution of Servlets from the Resources ?
> Would the Content.getComponentId be replaced by something which returns
> an URI to be interpreted in the context of the used scheme, such as
> jcr:, file:, oder osgi-service: ?...

That might be a ResourceToServletMapper, which takes the Resource URI
and maps it to an URI that allows a Servlet to be selected.

In the simple case (which is probably all we need now), the Servlet
URI would be an OSGi service URI, for example
osgi-service:/<serviceName> as you suggest.

Thinking in terms or URIs makes us more open to alternate schemes,
without (I think) complicating what we do now.

> ...Thinking about it, this seems interesting as for example, the
> DefaultContent class currently returns the primary node type as its
> Component ID (if not overwritten). It could return
> jcr:/types/<node-type> which could be handled by the JCR handler to find
> a Resource which actually is a Servlet ?? Other resources might use
> osgi-service:<serviceName> and allow the OSGi service handler to select
> a registered Servlet service ?...

Yes, sounds interesting!

>
> ...And then the jcr:/types/<node-type> resource may either be another
> "descriptor" like today's ScriptedComponent or it may actually be a JSP
> script or the root under which the JSP script would be found ? Would
> then this JSP script or JSP selector script root have to be of a certain
> node type ?...

"the root under which the JSP (or another language) script is found"
is the first option that comes to mind, and it could probably simply
be an nt:file node?

The Resource being processing is then mapped to a folder where
processing scripts are found. It's more or less the same as before,
but with more possibilities for reuse (i.e. having a file:// URI
instead of a jcr:// URI for scripts, where people need that).

> ...So, in fact the SlingHttpServlet would be much like today's
> ScriptedComponent of the scripting-core bundle ?...

Yes, again not much change compared to what we do now - mostly a
slightly more generic view of it, that could help more people gain
interest in this particular part of Sling.

> ...I like the enhancement of using such uniform names based on the HTTP
> method. Would there be some fallback mechanism, say e.g. if there is no
> post.* method for a POST request, we would take a get.* ?...

Dunno - I'd make this configurable maybe, either "strict HTTP
interface names" or "relaxed names".

-Bertrand