forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject file: prefix, take 2
Date Thu, 19 Dec 2002 16:00:14 GMT

Jeff, it seems to me that you were pissed off by my veto on your file: 
prefix system.

I have tried to explain you what my issues are, and have understood your 
vision. I have understood some of your points, and you have seen some of 
mine. This shows IMHO that the commit was really too hasty. But the 
thread degenerated again, so I want to start anew with it and get to a 
solution.

Try to understand that it's very difficult for me to stand behind this 
veto, it's not a fun ride. Don't think i made it lightly, nor that it's 
a personal thing.
Please give me all the time we need to resolve this thing, because it's 
IMHO important for Forrest.

                                -oOo-

This whole issue is about having the possibility of specifying in the 
links that I want to serve a file statically instead of having it served 
with transformation from Cocoon.

   href="myfile"       gives me index transformed by cocoon
   href="file:myfile"  gives me the file as-is

I have these point in mind, that logically drive me to the conclusion 
that the file: scheme is not correct.

  1 the source URI space is different from the destination URI space.

  2 since Cocoon should be free to transform the files in any way,
    thus possibly resulting in different result mimetypes in different
    skins/versions, we identify every file only as a filename without
    extension, even if the extensions are there.

  3 since the path without extension identifies the file, and since
    there is only one file with a given id, we can have only one
    file with the same name in the same dir.

  4 every destination "dir" can thus have only one file with
    the same name

Now, given that

  5 every file with the same path in the source space should
    be available in the same path in the destination space.
    Mounted spaces can be attached to the URI space anywhere,
    but must keep the dir layout relative to that.
    "Same" basically means that they must be in the same dir as
    source or as result, even if the dir will change in case of
    mounts.
    This is because placing them in the same dir has a meaning.

    example

      ./src/documentation/a.xml
      ./src/documentation/b.xml
      ./src/documentation/c.xml
      ./src/documentation/path/d.xml
      ./src/documentation/path/e.xml

      ./external/path/to/1.xml
      ./external/path/to/file/2.xml
      (both mounted in resourcemap)

may go to

      http://mysite/a.???
      http://mysite/b.???
      http://mysite/c.???
      http://mysite/path/d.???
      http://mysite/path/e.???

      http://mysite/the/mount-path/path/to/1.???
      http://mysite/the/mount-path/path/to/file/2.???


  6 every file with the same path+name in the source space should
    yield one only file with the same name as a result per content type.

  7 every file in the resulting space that has the same name
    but different content type must originate from the same source.

Then I conclude that

8 every source"dir" can thus have only one file with the same name

Now, this defeates one of the needs of the file protocol to identify the 
file to process, because there is only one file with a given name.

Now, for proper separation of concerns between the editor and the 
generation, the editor should not know anything about what Cocoon does 
to the file. He just puts a file in a dir and wants it served.
He knows that it will show up in the same path, or in the mounted path, 
and that it will have the same name, not necessarily the same extension.

In this scenario, what do we need the file: scheme for?

                                -oOo-

Practically, we have the problem of having to check which file we should 
serve. Why? Because the filesysem insists to encode the mime type in the 
name, as an extension.

Cocoon would have to be able to ask for the file with a certain name 
without the extension, and then ask for the mimetype.

I said that we needed resource-exists, but actually it's not needed.
We need an Action or similar that given a path, it gets the contents of 
that path, gets all the filenames, strips the extensions, maps them to 
mime-types, and then Cocoon can select based first on the mime-type of 
the source, and then eventually on the XML DTD with CAPs.
In essence, we probably need CAPs for directories instead of files.

I want to see one filename, one dir, one result, one link.

   source: /path/filename.any
   result: /mount/filename.any2
   link:   /path/filename

Cocoon would do:

   source: /path/filename.any
                   |
                   |
                   V

  {name://{1}/{2}} +  {mime://{1}/{2}}

  then select on mime
  then if xml select on DTD

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


Mime
View raw message