commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <Philippe.Poul...@sophia.inria.fr>
Subject Re: [VFS] uri style resolve names
Date Mon, 29 Aug 2005 13:22:52 GMT
Mario Ivankovits wrote:
> Hi Philippe!
> 
>>> No answers to this topic?
>>
>> not during my hollidays :)
> 
> Hope you are full of energy now ;-)
> 

bugs are frightenned of my return ;)

> 
> I read your new post and might comment in detail later - overall we are 
> on the same line, except for one thing:
> 
> *Is it really worth it?*

sure !

> 
> I am still not convinced in this very basic question. It IS a lot of 
> work and introduce some new logic a user might have to deal with.
> Currently we have a "Very Fine and Simple" (VFS ;-) ) wrapper around 
> some filesystems and I tried and still try to remove any logic from VFS 
> which I found not necessary.

this is the reason for which it is necessary to have a *common* 
resolution mechanism ; resolving names are scheme independant ; but as i 
said in my previous post, a name could contain an information about the 
file type : if it is a real DIRECTORY or not ; we are sure if a name 
ends with "/", but we should "normalize" names by removing the trailing "/"

URI resolution is really a problem to solve on the foundation of VFS

user side, they just have to append a "/" if they really want to force 
VFS to understand a name like a directory (that's what i did in my XML 
catalogs)

> 
> Everyone is free to add its own VfsUtils.resolveNameURI() class/methods 
> which behaves the URI way.

too late ! the trailing "/" will be lost after "normalization"
this normalization must be done, because in any case you still have a 
problem with "/path/to/name" and "/path/to/name/" ; they musn't be 
different, as you noticed it yourself ! the only thing we are sure, is 
that the former is a DIRECTORY, the latter is IMAGINARY, until it is 
attach()ed or createDirectory() is used

that's why a FileType field is needed in the name ; i noticed that 
AbstractFileObject.type could be easily moved to FileName.type because 
its constructor needs a FileName

> In difference to VFS which has to deal with filename-types 
> (directory/file) to work in all cases, such a method might only work if 
> the file/directory already exists, but I think this is the major case.

well, not really : we are really talking about *name* resolving, which 
is (must be) transparent to the underlying FS : resolving names are 
scheme independant

example where content is not accessed :
I work with XML catalogs where URIs are resolved from base URIs : when 
an entry URI is handled, its content is never used (never attach()ed) ; 
the content of the resolved URI on the other side is used
but in some case, it is not used ! for example, it may be use to build a 
link ; a web application won't do anything server side with a URI ; the 
web browser client side will

> 
> 
> Please give me some more arguments other than "your filename looks like 
> an URI so you should behave like an URI".
> Its easy to add a comment on the website which state the filename is NOT 
> a URI.

what would be the consistency of VFS in this case ?
how to resolve *names* with VFS if relative paths were used in HTML 
files ???

concessions have already been made regarding URIs by adding semantic to 
  "!" to allow scheme embedding ; but it was *necessary* ; now what 
people would think if they use a tool that is *deliberately* not 
compliant to RFCs ?

i already have to deal with such a problem : a vendor was using "URIs" 
that were not well-formed regarding RFCxxx ; it looks like this : 
"foo://path/to/file" ; but when i parsed the URI, the URI parser tells 
that the path part was "/to/file" and the host was "path" ; they simply 
forgot a "/" ("foo:///path/to/file"), becaming not compliant with RFCs ; 
it doesn't look professional :( ; one solution was to parse twice this 
pseudo-URI : 1 to fix the problem, 1 to use the standard URI parser ; 
that's what people hate to do : a hack so that they can use their 
preferred tools (that are compliant to standards)

you will regret sooner or later to break this ; VFS would be more used 
if you proclaim that you are RFC compliant except for the usage of "!"

i'm sure you know i'm right :)

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


Mime
View raw message