Philippe Poulard wrote:
[X] Use URI style
[ ] Keep current behaviour
people that vote for the second choice should consider this :
are your applications really impacted ?
i don't think so;
In fact it is impacted.
Lets summarize again:
From "URI point of view" every filename in VFS points to a directory
and thus resolveName resolve relative to this name - NOT to the parent.
1) file:///path/to/dir , any/file = file:///path/to/dir/any/file
2) file:///path/to/dir/ , any/file = file:///path/to/dir/any/file
With "URI style" and NO synchronization (attach) to the filesystem:
3) file:///path/to/dir , any/file = file:///path/to/any/file
4) file:///path/to/dir/ , any/file = file:///path/to/dir/any/file
With "URI style" and WITH synchronization (attach) to the filesystem:
5) file:///path/to/dir , any/file = file:///path/to/dir/any/file
6) file:///path/to/dir/ , any/file = file:///path/to/dir/any/file
Not only that the change to "URI style" resolving might break existing
applications (difference between 1+3) it requires to attach to the
filesytem to avoid this problem (5).
notice that URI resolution is scheme independant and applies only on
FileName, not on FileObject
But this is just a matter of definition, we are also free to say the
current resolution is scheme independant. The current way is surely not
RFC compliant, the question is if the URI resolve thing is the best idea
for filesystems.
(VFS doesn't need to attach() the file to the underlying file system
to lookup by itself if it is a real file or directory, except if a
user explicitely attach() the file)
As you might see, VFS needs to attach the file to resolve correctly if
the user do NOT always state a directory with the leading "/".
Now that we see we have to attach the file the question is if we simply
change resolveFile to check if the base-fileObject is a file or
directory/imaginary?
In the first case we ask the parent fileObject to resolve in the latter
we resolve like today.
BUT - this is something a user can do today with its own
VfsUtils.resolveFile() method.
Then there is still the problem to mark a filename as directory in advance.
If you use VFS as singleton (VFS.getManager()) and resolve the same file
you will get the SAME FileObject/FileName instance. e.g. it allows
threads to synchronize against a fileobject.
Now what if the first thread uses "file:///any/name/" and the second
uses "file:///any/name" - the first thread should see a filename in
state DIRECTORY and the second in state IMAGINARY until the file is
attached or created.
I admit, a very uncommon situation, but we have to deal with it.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
