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 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.
> 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"?
eg
xmldb://host/services/service_name?param=value¶m=value
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.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
|