Mario Ivankovits wrote:
Hi Philippe!

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

I disagree : "/path/to/dir/" denotes definitively a DIRECTORY ; don't need to attach()

Yes, I know - the DIRECTORY case is easy, but lets discuss the case - which is to major case for now

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 :)

people that use java.net.URI won't switch to VFS if they don't recognize the behaviour they know

forcing to attach is a very very bad idea : many applications based on catalogs are using URI to play with names, the underlying FS is not necessary accessible or even not really exist

have a look at the *3* reasons that appears in the *abstract section* of this document :
http://www.oasis-open.org/committees/download.php/13640/xml-catalogs.html
they talk about difficulties on handling ressources that are not necessary related to XML : it is true for every application that need to manage resources

having a way to resolve *names* is crucial

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 :(

however, there is a smart solution that should suit to *everyone*
-let the fsm.resolveFile( base, uri ) behave as you want
-change fsm.resolveName( base, name ) behave as i described

as i said previously, a flag should indicates on *FileName* if it is a directory or not ; it could be a free field that a user could set at convenience, but that is set automatically to true if the name ends with "/" ; so, even if a user use fsm.resolveName( base, name ), it could still decide by its own if attach()ing is needed or not

a custom resolveFile() method can't be considered if this flag is missing

remember that the more you are compliant with RFCs, the more VFS will be use :)

--
Cordialement,

           ///
          (. .)
 -----ooO--(_)--Ooo-----
|   Philippe Poulard    |
 -----------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to