cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <>
Subject Re: [RT] Cocoon Emotional Landscapes
Date Thu, 12 Oct 2000 14:40:40 GMT
On Thu, 12 Oct 2000, Stefano Mazzocchi wrote:

> Matt Sergeant wrote:
> > 
> > >  - the XSP language (eXtensible Server Pages)
> > >  - the sitemap concept
> > >  - the resource view concept
> > 
> > My only gripe would be that Cocoon somehow invented these
> > concepts. DataChannel invented XSP, the sitemap "concept" is built into
> > Apache (via <Location> tags and options between those tags)
> The "cocoon sitemap" concept is that you compose the pipelines using
> modules.
> For sure it takes from the Apache sitemap, but Apache sitemaps are based
> on URI matching only, don't have module chaining, don't have the notion
> of views, don't have a bunch of other things.

All of that is, I think, fairly debatable. Handlers can be chained
(although filtering isn't built in, but you can store in the notes table
to emulate filtering in Apache 1.x). And sure it could support views. It
depends what your module does, and how it interprets configuration options
you supply. If you like I can translate your example sitemap to an AxKit
equivalent to show how this can work with Apache 1.x's current config

> And they are not compiled but interpreted.

Dubious. httpd.conf is read at startup time, and values sent to the
respective modules, and the values stored in an apache table
structure. htaccess files are slightly different, of course.

> There is huge difference between Cocoon sitemaps and Apache conf file.

Like I said though, innovation, not invention.

> > and resource
> > views are certainly available in other application servers (before Cocoon
> > ever existed), MediaSurface comes to mind. Innovative, not inventive,
> > IMHO.
> Like I wrote in the article, "resource views" are a specific flavor of
> "resource variants" and resource variants are explicitly written in the
> HTTP RFC so I'm sure others implemented ways to have "resource variants"
> in their web technologies.
> But I think there is no web technology out there that provides the
> concept of "resource view" as I designed it: a projection of a
> multi-dimensional resource onto the requested hyperplane.
> The "resource variant" concept doesn't take into account
> multi-dimensional separation of concerns nor considers the resource
> multi-dimensional.
> It's a very different thing, even if I agree that all resource views are
> resource variants.

OK, I think I can just about parse what you're trying to say there, even
though most of it doesn't make a huge amount of sense to me. It seems to
me to be saying that you have a way of configuring the same URI to produce
different content by different means (and different modules), using
different methods of detecting exactly what to produce (content
negotiation). I don't see this as something Cocoon can really claim to
have invented per-se. You could do the same stuff in AxKit too, and I
don't follow Cocoon development (I pretty much just check in on [RT]
stuff), so I'm certain other people must have thought of this too.

But I don't want to argue it - its about time we started developing
technologies around these nearly 3+ year old specs!

> > Oh, and you should say 6 years, not 10, for when companies ignored the
> > web. Companies didn't even have the possibility of using the web 10 years
> > ago (its almost shocking to think it was all that recent...).
> Why not? it was there. The first implementation dates 1989.

It started off just being in Universities (anyone remember regularly
checking wuarchive for new uploads?), back when there was more content on
gopher. In October 1993 there were 200 known HTTP servers (cf 1994 is when it really took off, IIRC. So
I think 6 years is about right. Your history of the web may vary :-)


    /||    ** Director and CTO **
   //||    ** Ltd   **  ** XML Application Serving **
  // ||    ** **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site:     **
    //  \\

View raw message