forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject URI spaces: source, processing, result
Date Wed, 11 Dec 2002 14:34:59 GMT

Last commit of Jeff about the "link:" usage and my commit about 
resource-exists everywhere are all tentatives to resolve an issue that 
is still unfortunately open. Add to that topicmaps, linkmaps, and local 
dir hierarchy, and we definately have an issue to solve about URI spaces.

Now, IMHO these things are being difficult to resolve because we mix 
problems together, so I'll try here to separate them in different sections.


SoC means that the user should not tell the system how it wants the 
files to be processed. It just puts content on the disk and Forrest 
creates a site out of it.

  URI space

URI space is about concepts, not about telling Cocoon what pipeline to 
call. Hence the final URI space should be completely freeform.

For example, we should not require users to have images in **/images/** 
to be able to serve them. This means that we have to understand what 
processing to do to the files before displaying them.

Some think that it only applies to the output URI space (1) not the 
local directory structure (2). Hence the two local file placement 
approaches are like:




Personally I like (2), but we should also cater for case (1), and even 
make it possible to mix ways.


Going down the completely semantical URI space, we need to also tackle 
the file exxtension issue. So links IMHO should generally be done 
without using file extensions.

When a certain resulting mimetype is needed, it should be specified in 
another attribute of the link.

Links can be saved in a general linkmap that associates link shorthands 
with actual links. These links can be used by (example):

   <link href="linkmap://my/linket">...</link>

And have something like


This could also take care of a Stylebook feature we miss.

  Source Mounting

We should be able to include external directories in our local contents.
For example, if I have




I may want to make Forrest work as if the javadocs were in


without having to actually move the files there.

This is not only about files that must be served as-is, but also served 
as if they were in the normal hierarchy (ie xdocs).

This means that probably we should make our own sourceresolver or 
filegenerator and have that keep a mounting config that can tell where 
to get the files.
Or maybe just a SourceMountTranslate action to be called before every 
generation, that resolves the real source path, given the mount point.

Thus linking to these external resources will be done exactly as if they 
were in the normal dir space.

Does this make sense?

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

View raw message