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

[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