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] 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 java.net.URI 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 
URI("tar:file:///path/to/any/tarfile.tar!/within/tar/file.txt");
System.out.println( uri.getScheme() );
System.out.println( uri.getSchemeSpecificPart() );

result :
tar
file:///path/to/any/tarfile.tar!/within/tar/file.txt

then extract the parts :
-external URI :
file:///path/to/any/tarfile.tar
-internal path :
/within/tar/file.txt

> 
>> 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) 
VFS.getManager();
             fsm.setBaseFile( new File( System.getProperty( "user.dir" ) 
) );
             FileObject fo = fsm.resolveFile( "foo" );
             System.out.println( fo );
         } catch ( FileSystemException fse ) {
             fse.printStackTrace();
         }

result :
file:////path/to/current/dir/foo

> 
>> 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 :
http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/active-tags/active-tags.html#N4003C1

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

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