commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <>
Subject Re: [VFS] questions and suggestions
Date Wed, 11 May 2005 08:53:25 GMT
Mario Ivankovits wrote:
> 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.

but here the buffer has the size of the file ; usually, one uses a tiny 
buffer on which one perform read/write operation

>> =================================================
>> Question : why not use parser ?
> The VFS filename isnt a "correct" uri/url.
> It is possible to have something like this
> tar:file:///path/to/any/tarfile.tar!/within/tar/file.txt
> as you might see it is possible to have multiple (layered) schemes.

URI uri = new 
System.out.println( uri.getScheme() );
System.out.println( uri.getSchemeSpecificPart() );

result :

then extract the parts :
-external URI :
-internal path :

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

         try {
             StandardFileSystemManager fsm = (StandardFileSystemManager) 
             fsm.setBaseFile( new File( System.getProperty( "user.dir" ) 
) );
             FileObject fo = fsm.resolveFile( "foo" );
             System.out.println( fo );
         } catch ( FileSystemException fse ) {

result :

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

I didn't notice any trouble

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

you're probably right, "urn" should have its URNFileProvider
however, it's also a provider to which subschemes have to be registered 
; happily, VFS supplies all the machinery for this purpose

>> Suggestion : adding a capability to deal with I/O services
> Or implement your own (virtual) directory called "services"?
> eg
> xmldb://host/services/service_name?param=value&param=value

I don't like this solution because :
-it's a hack, I prefer more formal solutions ; the XML:DB spec offers 
specific means to get a service, not arbitrary URIs
-what happened if a real directory called "services" already exists ?

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

and this one is a really good idea ; anyway I still think that this 
interface could be part of VFS (with Capability.SERVICE)

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

not exactly, even if the feature you mention might be also usefull

I was thinking of a copy mode that copies files that has changed on the 
destination, and removes files that were removed on the source ; of 
course, files copied preserve the last-modified-date ; it's a mirroring 
on demand, not the automatically mirroring you mentionned

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

you will see how XPath is used is many examples here :

as you see, XPath allows to handle non-XML objects not limited to files


           (. .)
|   Philippe Poulard    |

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

View raw message