commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [VFS] questions and suggestions
Date Tue, 10 May 2005 17:43:21 GMT
Philippe Poulard wrote:
> Suggestion : Using NIO
NIO is since jdk 1.4. Currently we havent stated we move to the next jdk 
so we have to stick with jdk 1.3.

> Anyway, in the original code, the IS is put in a byte[] ; isn't that 
> dangerous when dealing simultaneously with very large files ?
Why? Every "copy" has its own byte buffer.

> =================================================
> Question : why not use parser ?
The VFS filename isnt a "correct" uri/url.

It is possible to have something like this

as you might see it is possible to have multiple (layered) schemes.

> I encountered files that were stored with "file:////" instead of 
> "file:///" ; did I miss something ?
Do you have a test to reproduce this?

> Suggestion : dealing with opaque URIs
> the FileObject method URL getURL() is somewhat restrictive ; it should 
> be replaced by URI getURI() because a FileObject is not necessary 
> accessible with an URL
the getURL returns an URL Object with its own URLStreamHandler so that 
every class accepting a URL and using this URL to retrieve any child 
automatically uses VFS under the hood.
If there is a problem with this it might be a bug in VFS.

> this is important because I also plan to implement some URN schemes, 
> if I have enough time
Why do you think it is needet to have URN in VFS? Or - couldnt URN be a 
VFS-Scheme with its own URNFileProvider which is aware how to deal with 
the following namespace?

> Suggestion : adding a capability to deal with I/O services
Or implement your own (virtual) directory called "services"?

maybe the result might be retrieved using getAttributes() or you 
implement a minimalized Service interface on the FileObject and cast the 
resulting object to this Service interface

((Service) fo).getResult();

Just an additional idea.

> Question : I didn't found in the todo list something that looks like a 
> synchronized copy ; is there an obvious implementation or nobody ever 
> thought about it ?
Did you mean with "synchronized copy" that all file-operations are 
automatically mirrored on a different filesystem?
Then yes, nobody ever thought about it.

Implementing this might be tricky but should be possible. At least it 
would make sense to implement a method where one can decorate a 
FileObject and thus can wrap it into something which will synchronize 
every file operation on a different filesystem/directory.

> Misc : I've seen in the Todo list : "Add more selectors: XPath"
> I use myself VFS to traverse file systems with XPath ; that' fine 
> because one can use XPath expressions like this :
> io:file( '/path/to/my/xml/docs' )//*[@is-file][ends-with( name(), 
> '.xml' )]
> I create a wrapper for FileObject (that also extend FileObject) that 
> gives an XML-friendly object, that is to say that behaves like an XML 
> element that is traversable with XPath
This looks interesting. Is it possible to see more examples about how 
you use XPath.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message