cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [C2] Link filtering and Content aggregation
Date Tue, 03 Oct 2000 10:35:17 GMT
Ross Burton wrote:
> > If you only used stylebook, I know you love it and don't see any
> > problems with it: it's a magic tool that does the job for you (more or
> > less an autodoc)... but if you ever tried to write a skin for it...
> > well, you know what I mean when I say there are problems.
> Do _not_ remind me of the time I wrote a new skin for Stylebook!

> > link filtering
> > --------------
> >
> > IMO, we need to expand the sitemap semantics to allow resources to be
> > blocked from CLI crawling. The best way, IMO, is to add a specific
> > attribute to the resource indicating elements... these elements are
> >
> >  - match
> >  - mount
> >
> > and we just have to define an attribute name between
> >
> >  - crawl
> >  - crawlable
> >  - walk
> >  - walkable
> >  - ???
> >
> > for example
> >
> >  <map:match patter="someuri" crawl="no">
> >   ..
> >  </map:match>
> >
> > will return a specific error number to the CLI requesting the page.
> >
> > What do you think?
> The sitemap needs this sort of flexibility, there could be a section of
> the URI space which could potentially return gigabytes of files (for an
> example, see  I'm +1 on... crawl="yes|no".

Ok, cool.
> > Content Aggregation
> > -------------------
> >
> > It was already proposed to use the "cocoon:" protocol and to access them
> And I'm a big +20 on this.

Yes, we definately need this kind of flexibility.
> > so
> >
> >  <sitebar xinclude:href="cocoon:/sitebar"/>
> >
> > is expanded at runtime as
> >
> >  <sitebar>
> >   <item xlink:href=".."/>
> >   <item xlink:href="index"/>
> >   <item xlink:href="user-guide"/>
> >  </sitebar>
> I take it that in this example the resource /sitebar returns the XML:
>   <sitebar>
>     <item xlink:href=".."/>
>     ....
>   </sitebar>
> And _replaces_ the original <sitebar> element.  The same behaviour would
> be the same if the original element was, for example: <foo
> xinclude:href="cocoon:/sitebar"/>, right?


> I'd feel safer using just
> <xinclude:include href="cocoon://sitebar"/>, as I think the syntax is
> clearer.

Well, the latest xinclude spec uses attributes as behavioral specifiers
not elements and I think they are totally right on this (they follow the
orthogonal behavior of xlink attributes).

Today there is no such ability, but I really hope in the future it will
be possible to allow attributes to 'connect' their values to other
attributes... something like this

 <element name="include">
  <attribute name="href"/>
  <attribute name="href" ns=""

so you will be able to things like

 <cocoon:include href="cocoon://sidebar"/>

which will be totally equivalent in functionality without breaking the
spec (and much more elegant IMHO)
> Oh, IIRC the URI RFC states that the format is protocol://host/path

Are you sure about this? this the format of the HTTP URI... but
generally speaking, even a:b is a valid URI for the RFC 2396.

>, so
> the resource should be cocoon://sitebar or cocoon:///sitebar depending
> on the sitemap.

Hmmmm, I have to read the RFC again, but I'd suggest we treat them as
equivalent... so there is no difference in behavior if you have


this si because people might try to do things like


which is clearly invalid since there is no way to have a RPC on a remote
Cocoon (nor a need to have it in the future!!)
> This requires a custom URL handler, doesn't it?

Not necessarely.

I have a plan to create a pluggable protocol handing infrastructure in
Avalon which stays on top of the classes but provides a way
to register your own protocols handlers.. Something like

 URLFactory URLFactory.createFactory(Object myself);
 URL URLFactory.createURL(String url) throws ProtocolNotFoundException;
 void URLFactory.registerHandler(String protocol, URLStreamHandler

> How is this going to be handled?  org.apache.cocoon.utils.URL?

No, this is general enough to belong to Avalon, I think. Almost
everybody on the server side lacks the feature of adding new url
handlers... it's time to move away from the JDK limitations and create a
better URL infrastructure.

Don't you agree?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message