forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Filesystem layout (Re: Skin rewrite: 0.2 release?)
Date Tue, 12 Nov 2002 10:53:55 GMT


Jeff Turner wrote:
> On Tue, Nov 12, 2002 at 10:10:37AM +0100, Nicola Ken Barozzi wrote:
> ...
> 
>>>Implication: you
>>>want a semantic filesystem layout, as well as a semantic URI space.
>>>Files are arranged according to what the _mean_, not what the _are_.
>>>
>>>Example: if we wanted:
>>>
>>>http://mysite/license
>>>
>>>then it's contents should be obtained from content/license.*, where the
>>>extension (if present) is purely a hint to the sitemap as to which
>>>pipeline to use.
>>>
>>>Is that what you're getting at?
>>
>>+1
> 
> good good..
> 
>>>My take on this is that the filesystem should be organized FIRST on
>>>content type, THEN on semantics.  A direct analogy:
>>>
>>>FIRST we order projects by file type:
>>>
>>>src/java
>>>src/test
>>>src/scripts
>>>src/etc
>>>...
>>>
>>>THEN, inside each directory, we order by meaning:
>>>
>>>src/java/..../myproject/parsing/*.java
>>>src/java/..../myproject/servlet/*.java
>>>src/java/..../myproject/util/*.java
>>>
>>>
>>>Likewise, in Forrest we should order first by type:
>>>
>>>content/xdocs
>>>content/images
>>>content/html
>>>
>>>then by meaning:
>>>
>>>content/xdocs/*.xml
>>>content/xdocs/drafts/*.xml
>>>content/xdocs/manual/*.xml
>>>content/images/*.png
>>>content/images/drafts/*.png
>>>content/images/manual/*.png
>>>content/html/sitemockups/*.html
>>>
>>>
>>>Why do the initial split by content type?  Two reasons:
>>>
>>>- Users prefer it.  It provides a way of ordering one's project.  Users
>>>  don't _want_ images and xdocs all jumbled together.
>>
>>I disagree.
> 
> Then please describe why Centipede doesn't have one big src/, given that
> it's technically possible.

Because that's how users that have been polled have replied.
For exmaple, we are planning to have a single src dir and compile the 
files in the packages indipendently, using the Gump descriptor dependencies.

>>Users have explicitely asked me to be able to have images where the
>>content is.
> 
> "images where content is".. if you mean, move resources/images to
> content/images then I'm all for that.

<grrr>

>>Some are @ Avalon, not newbies.
> 
> 
> Please direct them to this list in future.  Evidently they didn't know
> that this can be easily achieved with:
> 
> project.images-dir=${project.content-dir}
> project.xdocs-dir=${project.content-dir}

Maybe it was before Forrest got to that point ;-)

> That's the point: the current system, while supporting a structured
> approach, _allows_ the unstructured approach if desired.  The reverse is
> not true: if we go down your route of a sitemap full of
> general-as-possible rules, we can never go back.  Fine-grained can
> emulate coarse-grained, coarse-grained cannot emulate fine-grained.

Again, I want *both* rules to apply in the same time.
That is I can put images in both places and have them delivered.

>>>- Simple pragmatism.  In projects, Ant needs to apply operations to
>>>  _types_ of files, regardless of meaning.  In Forrest, exactly the same
>>>  thing: we need to apply transformations based on _types_ of files,
>>>  regardless of semantics.
>>
>>DTD states the type. It's in the file.
> 
> 
> Just like Centipede could identify JUnit test cases with:
> 
> <fileset dir="src/" includes="**/*.java">
>   <contains text="extends TestCase"/>
> </fileset>

In fact it can and it probably will.

> So again, given the technical feasibility, why doesn't Centipede merge
> src/testcases and src/java?  Perhaps because.. it's a really dumb idea
> that users won't buy? :)  If users won't buy it in Centipede, why would
> Forrest users buy it here?

Every web server does it, don't you know?  :-PPP

>>>As for the second reason: yes we could 'infer' the content type by
>>>looking at the extension, just like we could compile *.java wherever it
>>>occurs under src/.  I just think it's cleaner to match on directory
>>>rather than extension.
>>
>>Why?
> 
> For the same reasons an Ant script is made simpler by partitioning src/.
> Everything is made simpler.  To start with, validation, which is the tip
> of the iceberg of things broken in forrest.build.xml if we keep your
> patch.  We might as well throw away forrest.build.xml and start again,
> because right at the core is the assumption that content is separated by
> type, and named with ${project.*-dir} properties.

This is just a technical thing that can be overcome.
I'm not going to make design decisions just because it's easier.

>>A gif file is a gif file whether I put it in a certain dir.
>>If I *have* to do it it's because something is not clever enough to 
>>understand it for me.
>>
>>
>>>Here's a question: why does Centipede separate src/java from
>>>src/documentation, when technically Ant could easily deal with everything
>>>in a single src/ directory?  Why not, as you suggest for Forrest, order
>>>by semantics, not type:
>>>
>>>src/util/*.java 
>>>src/util/*.xml      # xdocs for 'util' code
>>>src/servlet/*.java  # servlet interface
>>>src/servlet/*.xml      # xdocs for servlet interface
>>>
>>>In fact, why not throw src/testcases/ in there too; we could always use
>>>Ant selectors to distinguish JUnit source from normal source, just like
>>>CAPs distinguish types of XML.
>>
>>Why does Java ask us to put html descriptions of the packages *in* the 
>>class dirs?
> 
> Because Javadoc cannot assume otherwise.  But note that javadoc also
> suggests that large quantities of docs be stored in doc-file/ subdirs.

I know, and in fact I never said I want to *prohibit* that kind of 
behaviour.

>>Why do we put properties there?
> 
> Laziness.  Personally I store non-Java files (manifests, properties,
> resourcebundles) in a src/res (resources) tree.  For large projects it
> really is much better.

Don't assume that your way of doing it is necessarily "The Right Way".

>>Because they are strictly related.
>>
>>Now, I'm not saying that we stuff *all* in the content dir, just *content*.
>>I think that gifs, html, xml, etc are all content, and all are the same.
> 
> Agreed.
> 
>>We still have a resources dir, and *there* I would like to see what you 
>>propose.
> 
> Ahem.. I am defending the status quo here, which you just broke ;P

Ahem...

>>So users can decide to put images in the content, or treat them as 
>>global "resources".
>>
>>It has been asked many times,
> 
> never on list...

Are you sure? What about Ken (IIUC) that wants to be able to have 
Forrest serve any file that's in the directory?

Probably I just also misunderstood Ken, Peter, Stephen, Cristina here at 
my workplace, etc...

>>I don't see technical difficulties,
> 
> perhaps you haven't examined forrest.build.xml recently?

I have, but not with this in mind.
I will soon.

>>I like it myself.
>>
>>What do others think?
>>What do *users* really think?
>>
>>
>>>Conclusion: history and experience show that ordering by type, and then
>>>by meaning, provides something that a) users like, b) is technically
>>>simple and unambiguous to deal with.
>>
>>My experience is different, that it's not always the case.
>>We must cater for both behaviours, and also mixed ones.
> 
> 
> +1.  Mine does, yours doesn't :)  Here's how the current system can
> emulate yours:
> 
> project.content-dir=src/documentation/content
> project.xdocs-dir=${project.content-dir}
> project.images-dir=${project.content-dir}
 >
> That _works_ right now.  

No, it doesn't. It doesn't cater for a mixed scenario and needs work to 
make it copy-less.

But validation is more important ATM, so I've reverted my commit.

> Any users who prefer a single content dir can do
> just that.  Sure, they'll get 3 copies of the content/ directory in
> build/tmp/, but it will work, and as soon as we eliminate the copy step
> (by parametrising the sitemap) that problem will go away.
> 
> 
>>On a list it has been written that some would commit images in the 
>>content and move them to resources if used by more pages, giving a 
>>simple migration path.
> 
> Can do that too.
> 
>>I like it.
> 
> 
> :)  I think we need a proper Forrest roadmap, with use-cases and a
> concrete, technical step-by-step guide, in order to prevent
> misunderstandings like this from happening again.

This was decided IIRC in previous discussions, and I'm sorry nobody else 
jumps in this discussion to state opinions or memories.

Anyway, you have the ball now.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message