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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org