Return-Path: <stefano@apache.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 43585 invoked from network); 3 Oct 2000 10:35:59 -0000
Received: from pop.systemy.it (194.20.140.28)
  by locus.apache.org with SMTP; 3 Oct 2000 10:35:59 -0000
Received: from apache.org (pv5-pri.systemy.it [194.21.255.5]) by
 pop.systemy.it (8.8.8/8.8.3) with ESMTP id MAA06353 for
 <cocoon-dev@xml.apache.org>; Tue, 3 Oct 2000 12:35:45 +0200
Message-ID: <39D9B665.3FEB5E7@apache.org>
Date: Tue, 03 Oct 2000 12:35:17 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en,it
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] Link filtering and Content aggregation
References: <200010021919.UAA01031@eddie.itzinteractive.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

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 rpmfind.net).  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?

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="http://w3.org/2000/xinclude"
inherits-from="href"/>
 </element>

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

 cocoon:/sitebar
 cocoon://sitebar
 cocoon:///sitebar

this si because people might try to do things like

 cocoon://myhost.com/cocoon/path/resource

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 java.net.URL 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
handler);

> 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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------