Vincent Massol wrote:
Hi Philippe,
-----Original Message-----
From: Philippe Poulard [mailto:[EMAIL PROTECTED]
Sent: lundi 17 juillet 2006 11:28
To: Jakarta Commons Users List
Subject: Re: [VFS] Why resolveFile API doesn't accepting URI ?
Vincent Massol wrote:
Hi Mario,
-----Original Message-----
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: lundi 17 juillet 2006 08:25
To: Jakarta Commons Users List
Subject: Re: [VFS] Why resolveFile API doesn't accepting URI ?
Hi!
I've just tried to use VFS and I was surprised to see that the
resolveFile
API does not have a signature accepting a URI object.
I think (this decision were felt before I jumped to VFS) the main reason
is, that vfs supports "layered" URIs. So you can have
tar:gz:http://www.......
The java URI class cant really deal with this, can it?
I think it can. See
http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html
They give this example in the javadoc:
urn:isbn:096139210x
In addition the general format is: [scheme:]scheme-specific-
part[#fragment]
I'm not an expert but I guess one could consider that the scheme is
"tar:gz:http" in your example above.
not at all : the scheme is "tar" and the scheme specific part is the
remainder ;
Ah right. As I said I'm not an expert ;-)
unfortunately, the URI class doesn't perform further parsing
for the other parts because the RFCs doesn't specify a separator ; VFS
uses "!"
What do you think would not work if VFS used an URI class? It seems to me
that getScheme() and getSchemeSpecificPart() will always return the full
URI, no?
I wrote a little unit test to ensure I understand what's going on:
public void testURI() throws Exception
{
URI uri1 = new URI("file://c:/anyhost/dir/mytar.tar.gz");
assertEquals("file", uri1.getScheme());
assertEquals("//c:/anyhost/dir/mytar.tar.gz",
uri1.getSchemeSpecificPart());
assertEquals("c:", uri1.getAuthority());
assertEquals("/anyhost/dir/mytar.tar.gz", uri1.getPath());
URI uri2 = new URI("tar:gz:http://anyhost/dir/mytar.tar.gz!/mytar.tar!";
+ "/path/in/tar/README.txt");
assertEquals("tar", uri2.getScheme());
assertEquals("gz:http://anyhost/dir/mytar.tar.gz!/mytar.tar!";
+ "/path/in/tar/README.txt", uri2.getSchemeSpecificPart());
assertNull(uri2.getAuthority());
assertNull(uri2.getPath());
}
As the general format is "[scheme:]scheme-specific-part[#fragment]" if we
used only the getScheme() and getSchemeSpecificPart() APIs wouldn't it work
just fine?
URIs are classified in opaque URIs and hierarchical URIs ; the uri1 in
your example is hierarchical, the uri2 is opaque, but it looks like a
hierarchical URI ; what we can't do with opaque URIs ? well... resolving
a relative URI regarding it
The scheme-specific part would be parsed as it's currently done.
In other words what do you think wouldn't work if we used the URI Java
class?
if you have to resolve URIs upon a base URI, you'll certainly have some
troubles if you have "layered" URIs à la VFS
what you need is a specific class that understand "layered" URIs ; it
could be a class based on the existing URI class ; what you have to do
is to test if you have an opaque URI if the scheme specific part up to
the last "!" is itself an URI
VFS works like this
--
Cordialement,
///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
