forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: URI spaces: source, processing, result
Date Thu, 12 Dec 2002 09:56:48 GMT

Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>> Does this make sense?
> I really don't know. I have been talking offlist to both you and Jeff, 
> and some of this is above my drugged head these days.
> Trying to bring the town of you together, I see there is some general 
> tendency to tolerate and even advocate some source:/ or scheme:/ like 
> think, if not for the same reason. While I love to KISS, the aspect of 
> having to declare my links in my future Forrest docs like <link 
> href="protocol:name"/> feels kinda good, protocol being things like
>  - javadoc
>  - code
>  - keyword
>  - index
>  - raw
>  - href (default)
>  - linkmap (indirection layer, also to aforementioned protocols)
> and name being a filename or a named resource name depending on the 
> protocol and the eventual indirection
> In terms of implementation, some of this will point towards SAXable 
> information that must be passed across Cocoon pipelines, some of this is 
> external data, perhaps binary in the sense of not being based on XML and 
> not serializable as such. So some of this information will require its 
> own Source implementation or Generator, some will just need to be copied 
> around, either as a file, or as a collection of files. Some of it will 
> require link augmentation or resolution, if linkmaps/indirection has 
> been used.

This mixes concerns.
The schemes should only be a link translating system.

> With regards to greater datasets, such as massive Javadoc collections, 
> I'm not sure whether we would need to try and keep this within the 
> concern of Forrest, at least in terms of the static generation of it - 
> there exist tools to do that. In terms of doing something with tools 
> like qdox, I'm not sure - I think this can be a value for the Forrest 
> user: <link href="src:/org.apache.cocoon.foobar"/> bring up a 
> syntax-highlighted version of that class.

The fact is that these systems should be pluggable, and not concern 
forrestr. But we should be able to easily resolve java source classes to 
a URI space, and that would call the correct generation stuff, be it 
actual generation, skinning or copying over.

> So maybe we end up with a number of scenarios for these scheme 
> implementations:
>  - triggering a pipeline generating the target of the link, where we 
> need mimetype based extension generation (see, I concur with you, Nicola!)

Yes, taking the extension away and putting a non-comupulsory mime-type 
attribute +1

>  - triggering some funny SourceWritinglikeTransformer, _moving_ 
> information as-is from source layout to output layout and 'tagging' the 
> link so that it doesn't get traversed anymore by the beloved CLI

We have readers for that. A readers reads the resource as-is.
The issue is not about how to get-copy it, but the crawling, that is 
slow, and doesn't work on readers.

So if I want to include a directory of stuff, it hass all to be parsed 
and put in XML format, so that links can be extracted and the stuff be 
crawled. It's the crawling that should be addressed.

>  - rewriting a link so that, based on some configuration, <link 
> href="javadoc:/org.apache.foobar"/> will be rewritten as <a 
> href="../../../build/javadocs/foobar.html"/> (I forgot how Javadoc 
> generates filenames)

+1 to this.

> That's the few scenarios I could come up with now. Do we need separate 
> components for those? Separate <link/> notations? Have these scenarios 
> implemented through passive or active components?...
> IMHO: "as few as possible", "no" and "active".

What do you mena by active?

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

View raw message