hi Mario,
Mario Ivankovits wrote:
Hi!
it must not : before VFS, I already disciplined myself and always name
my directories with an ending "/" ; i'm always sure what i'm handling :)
You strip the rest of my mail so I would like to append it here again:
-----------------------------------
The ONLY way I can see is to force the user to append the trailing "/"
ALWAYS if he would like to work on a directory, else it is a file.
It is no longer possible to work on "imaginary filanames".
The type can not be changed with a createDirectory/createFile.
The type of the filename says all.
AND VFS has to attach the file on resolveFile to check if the requested
type corresponds to the reality if the file/directory is already existent.
e.g. The request for file://any/dir will fail if it is existent and a
directory, on the other hand a createDirectory() will fail as the
filename points to a "file" not a directory.
There is still the problem with imaginary files and the order of
resolveFile in threading. But then we will have a fail fast (vfs will
throw an exception too) and this is somehow arguable and as I said a not
very common situation.
-----------------------------------
people that use java.net.URI won't switch to VFS if they don't
recognize the behaviour they know
Then the question is: Why should one use VFS?
If no physical access is needed and URI do its job then go on with it,
once you would like to access a resource you can pass the URI as string
to VFS.
because VFS does more than java.net.URI : VFS allows to process nested
schemes !
this is a great advantage because from an URI point of view, a scheme
embedded in a scheme is just an *opaque* URI for which -guess what- a
path resolution can't be done, ha ha !
additionally, VFS can also be use to access resources from URNs
http://www.oasis-open.org/committees/download.php/13640/xml-catalogs.html
Done.
if you still decide to ignore these important stuffs, you dramatically
restrict the application scope of VFS ; it would be a pain to hack VFS
in the aim of having a correct behaviour :(
Please dont say I igonre important stuff,
oh sorry, i don't say it !
I hardly try to understand
your needs and I try to tell you its implimications.
My main VFS usage is in an web-application as singleton and so there is
only one fileName and fileObject instance per resource in the whole JVM.
To have a flag and switch it back and forth WILL break threaded (and
thus web-) applications.
What ever you would like to have, you have to take this into account.
i understand
as i said previously, a flag should indicates on *FileName* if it is a
directory or not ;
yes!
good
it could be a free field that a user could set at convenience
no! not possible, every filename is a singleton in an jvm instance.
ok
, but that is set automatically to true if the name ends with "/" ;
ok
good !
a custom resolveFile() method can't be considered if this flag is missing
I know, and I expected it only to work when the resource is "reachable",
but ok, I understand that this is bad too.
remember that the more you are compliant with RFCs, the more VFS will
be use :)
hmmmm .... now that we are the only two discussing this topic I would
suspect that other user really need this feature, BUT HEY - I take you
seriously, I promise, maybe we just cant see the value of the URI solution.
I will try to widen this discussion and setup a text which I will send
you per PM. If you agree with the content I will post a poll on the
developer list. Maybe we can get additional input from there.
ok, thanks ; this interesting discussion makes things progressing
what about the other VFS designers/developers ? i saw other names than
yours in the source code ; what do they think about that stuff ?
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
