Return-Path: 
 <forrest-dev-return-4076-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org
Received: (qmail 12555 invoked by uid 500); 11 Dec 2002 15:16:27 -0000
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:forrest-dev-help@xml.apache.org>
list-unsubscribe: <mailto:forrest-dev-unsubscribe@xml.apache.org>
list-post: <mailto:forrest-dev@xml.apache.org>
Reply-To: forrest-dev@xml.apache.org
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 12543 invoked from network); 11 Dec 2002 15:16:27 -0000
Received: from smtp3.ihug.com.au (203.109.250.76)
  by daedalus.apache.org with SMTP; 11 Dec 2002 15:16:27 -0000
Received: from p134-apx1.syd.ihug.com.au (expresso.localdomain)
 [203.173.140.134]
	by smtp3.ihug.com.au with esmtp (Exim 3.22 #1 (Debian))
	id 18M8b4-0000mR-00; Thu, 12 Dec 2002 02:16:26 +1100
Received: from jeff by expresso.localdomain with local (Exim 3.35 #1 (Debian))
	id 18M8id-0002t0-00
	for <forrest-dev@xml.apache.org>; Thu, 12 Dec 2002 02:24:15 +1100
Date: Thu, 12 Dec 2002 02:24:14 +1100
From: Jeff Turner <jefft@apache.org>
To: forrest-dev@xml.apache.org
Subject: Re: file: implemented (Re: cvs commit: ...)
Message-ID: <20021211152414.GD3552@expresso.localdomain>
Mail-Followup-To: forrest-dev@xml.apache.org
References: <20021210115620.1021.qmail@icarus.apache.org>
 <20021210162430.GC4073@expresso.localdomain> <3DF67971.9070603@apache.org>
 <20021211093547.GB3552@expresso.localdomain> <3DF743BE.90408@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DF743BE.90408@apache.org>
User-Agent: Mutt/1.4i
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Wed, Dec 11, 2002 at 02:55:10PM +0100, Nicola Ken Barozzi wrote:
> 
> 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 
> >>convolution.
> >>
> >>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.

The filterlink.xsl stylesheet strips out links starting with 'file:', so
when Cocoon does a ?cocoon-view=links, the file: links aren't there.

>From that, I have a hard time seeing how to deduce:

> >>we are opening wide a door to abuse and failing of link checking.

<snip red herring on http: link checking>

> >>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.

Why does MIME type info matter?  What if a link has no easily guessable
MIME type, like <link href="foo.obj">?

> Hence we neeed the MimeTypeAction and fix the CLI so that it doesn't add 
> the "default" html to unknown mimetypes.

I think you'd have to remove the "append .html" behaviour altogether.

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

Let's fix the CLI...

<rant>
The CLI is evil and should have been drowned at birth.  The Cocoon CLI
can best be described as a crappy 'wget' implementation tacked onto the
side of Cocoon.  It is slow as hell, full of bugs (eg css images) and
practically unmaintained.  Rewriting wget in a corner of Cocoon was a
blindingly stupid thing to do, and I am not about to waste my time fixing
its bugs.  I would rather find a _real_ wget implementation in Java, that
can handle CSS and doesn't do screwy things with filenames, and IF
invoking Cocoon through the HTTP interface proves too slow (unlikely),
then I'd wrap Cocoon in an Avalon block and feed it URLs passed over RMI.
</rant>

Any enlightenment you can provide as to why the CLI _doesn't_ suck in
concept and implementation would be gratefully received.

But that is a side issue.  Yes, getting the CLI to stop appending '.html'
would fix the immediate problem.  Then when we come to implement a
'javadoc:' protocol, which will trigger further CLI problems.

> >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?

Cocoon can't handle these schemes, so we must either:

1) Hack the CLI to ignore them and rewrite the HTML
2) Edit filterlinks.xsl to prevent Cocoon from even seeing them.

> You are mixing concerns, I will make a new mail on this to rey and
> unroll the loops.

Please do.


--Jeff