forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: file: implemented (Re: cvs commit: ...)
Date Wed, 11 Dec 2002 13:55:10 GMT

Jeff Turner wrote:
> On Wed, Dec 11, 2002 at 12:32:01AM +0100, Nicola Ken Barozzi wrote:
>>Sorry if I'm a bit strong on it, but it creates more confusion and 
>>If we make links not be traversed in the definition,
> Who suggested that?  All links are traversed _except_ for those with
> specific schemes like 'file:' or 'javadoc:', which are handled specially.
> That is why I said the implied scheme is 'cocoon:'.

I mean if we define that a naming scheme blocks the traversing.

>>we are opening wide a door to abuse and failing of link checking.
> Actually with the current implementation, we can do _more_ link checking.
> Eg, we can record http: links (without rewriting them), and then later in
>, check if they really exist.

Cocoon has to do it, let's not do Ant post-processing on this.

>>My proposed solution is to
>>1) make Cocoon use resource-exists to see if it has to process it or not
> We already have a resource-exists check.  The problem is that the CLI
> adds a '.html' to the URLs of static resource, because it doesn't know
> that they are static.  

It's because it doesn't know the MimeType.
Hence we neeed the MimeTypeAction and fix the CLI so that it doesn't add 
the "default" html to unknown mimetypes.

It's a CLI bug and a missing feature, let's fix those instead of going 
round them.

> To fix this, the CLI would need access to the
> xlink:role attribute.  Every new scheme would require a Cocoon CLI hack.
> If we're going to have a proliferation of schemes, like 'site:',
> 'person:', 'javadoc:', 'mailinglist:', etc etc, doesn't it make sense to
> have 'file:' as well?  And deal with all of them in Forrest's sitemap,
> rather than the Cocoon CLI?  For instance, we _could_ hack the CLI to
> ignore links starting with 'javadoc:', but isn't it easier to prevent
> them being passed to Cocoon in the first place?  Then all support for the
> 'javadoc:' scheme is within Forrest XSLTs.

No no no, what has this to do with ignoring schemes?
You are mixing concerns, I will make a new mail on this to rey and 
unroll the loops.

>>2) if it has to process it, use CAPs to understand how
>>3) have the possibility of "mounting" documents from outside, ie if I 
>>mount the /my/javadocs to the javadocs: protocol, I link to 
>>"javadocs:index.html" and it gets resolved to the correct path.
> Yes.  I could implement javadocs: in half an hour if we can agree on
> where to obtain '/my/javadocs/' from.

Which is actually not the point, it has to be configurable ala linkmap...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message