Re: [VFS] uri style resolve names

[Mario Ivankovits <ma...@ops.co.at>]

No answers to this topic?

---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [VFS] uri style resolve names

[Philippe Poulard <Ph...@sophia.inria.fr>]

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

Re: [VFS] uri style resolve names

[Mario Ivankovits <ma...@ops.co.at>]

Hi Philippe!
>> No answers to this topic?
> not during my hollidays :)
Hope you are full of energy now ;-)


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

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.

Everyone is free to add its own VfsUtils.resolveNameURI() class/methods 
which behaves the URI way.
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.


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.

---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [VFS] uri style resolve names

[Philippe Poulard <Ph...@sophia.inria.fr>]

Mario Ivankovits wrote:
> No answers to this topic?

not during my hollidays :)

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