forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: file: implemented (Re: cvs commit: ...)
Date Wed, 11 Dec 2002 10:29:46 GMT
On Tue, Dec 10, 2002 at 05:04:06PM -0900, Matt Jones wrote:
> Jeffs commit looks great!  It would exactly solve a simple problem 
> simply.

Which is the best compliment.. thanks :)

> My only minor concern is that you used a scheme name that may be
> commonly found in URI's, ("file"), so you might want to consider
> something less prone to conflicts.

We could use raw: or source: instead, to emphasise that this scheme is
totally specific to xdocs interpreted with Forrest, and will be rewritten
in the output HTML.

However I think that when we have XMLs packed with interesting schemes
like site:, person:, javadoc:, mailinglist:, then file: will fit in
naturally as "this URL refers to a local file".

> I'm not as excited about Nicola's proposal:
> >My proposed solution is to
> >1) make Cocoon use resource-exists to see if it has to process it or not
> >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.
> >
> This is confusing.  I've been poring over Forrest for the last week, 
> trying to get it to do what I want, and this still doesn't make much 
> sense to me.  I've read cap.html and it seems mildly relevant, but 
> pretty darn indirect compared to having the document author directly 
> specify what they want done with files.  What would I do?  How would I 
> specify that x.pdf is not to be processed nor have its links mangled, 
> but y.pdf should be?  This proposal from a naive perspective seems 
> overly complex for what it provides -- very cocoon-like :)


> I can see a shadow of an idea forming there in which the user need not
> specify at all how to process these files, but cocoon would
> automatically know what to do with files.

Yes, that's the idea.

> But my guess is this will actually require complex configuration for
> each site that is not at all transparent to the user.

I don't think so.. the main problem is that it pushes handling of static
files into the Cocoon command-line.  With an explicit file: system,
everything is kept within the Forrest sitemap.  Proactive link handling,
rather than reactive.

But primarily, I prefer file: because it fits in with the broader
lets-have-lots-of-schemes theory of where Forrest should go.  We still
need to vote on that, hence I reverted the patch.  To get the file:
version of Forrest, type 'cvs update -r with_file_scheme'


> Matt

View raw message