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
> 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 e
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
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 futu
On 10/13/07, Felix Meschberger <[EMAIL PROTECTED]> 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 packa
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
>>
Hi all,
After the introduction of the topic by Carsten and some initial
discussion, I created issue SLING-28 [1] and committed a first
prototype. After having it around for some days now, I want to call for
a final discussion on this topic.
Is there anything, which would go wrong in this directio
On 10/4/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> ...After the introduction of the topic by Carsten and some initial
> discussion, I created issue SLING-28 [1] and committed a first
> prototype. After having it around for some days now, I want to call for
> a final discussion on this topi
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 a
On 10/8/07, Felix Meschberger <[EMAIL PROTECTED]> 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 int
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
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)
On 10/9/07, David Nuescheler <[EMAIL PROTECTED]> 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, t
13 matches
Mail list logo
