commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <>
Subject Re: [POLL][VFS] how to resolve relative filenames
Date Wed, 31 Aug 2005 07:14:34 GMT
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 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 : 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

> 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!


>> 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.


>> , 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 ?


           (. .)
|   Philippe Poulard    |

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message