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¶m=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' )//[EMAIL PROTECTED]( 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
