Philippe Poulard wrote:
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
Sorry, I didnt get it.
FileUtil.writeContent uses a small buffer (maybe too small) in its read/write loop.
Dont mix this up with FileUtil.getContent() as this will only used for the classloading stuff.
ok ; all is clear, now
Question : why not use java.net.URI parser ?
Ok, it might be possible, but then again java.net.URI is jdk 1.4 only.
file:////path/to/current/dir/foo
You are right, according to the documentation it should be file:///path/to/current/dir/foo
I will look into it. If you find some time it would be nice to file a bug at http://issues.apache.org/bugzilla
done : http://issues.apache.org/bugzilla/show_bug.cgi?id=34858
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 ?
You could also use a special scheme for this purpose, say: xmldbsvc://host/service_name/......
and this one is a really good idea ; anyway I still think that this interface could be part of VFS (with Capability.SERVICE)
I am not sure if this is really something which should be in VFS core, or maybe if havent understand it fully now.
What is the value of VFS if it only allows you to call a "service" on your filesystem and retrieve the result as a single object.
If I think on a JDBC stored procedure it isnt really easy to 1) call the method (you have datatypes) 2) interpret the result
Simply returning a object isnt what VFS would like to do. Its intention is to provide a view on the filesystem.
Now it might make sense if you have a JDBC FileSystem and the server provides a stored procedure to create a alternate view on it, but then the result of this "service" needs to be in a
form that VFS ist able to project to a hierarchical structure and the leaf can be retrieved using getAttributes and/or getInputStream.
In the case of a JDBC FileSystem the result might be a ResultSet.
But feel free to teach me :-)
here are some services defined in XML:DB
CollectionManagementService, TransactionService, XPathQueryService, XUpdateQueryService
(note that for XPathQueryService I think that QueryService was more suitable, because with the former name, designers restrict the query languages to XPath, which excludes normally XQuery and other XND proprietary request languages)
there is a service you have already thought about : "findFiles", but it is a method of a FileObject, because it is very close to what people are thinking about a file system
a service is just an advanced feature, such as findFiles which is obvious ; curiously, XML:DB designers thought that the services should depend on the collections (understand "directories"), that is to say that a service might depend on where you are on the file hierarchy ; I didn't experienced such a case, I always deal with services that are related to server connexions (scheme://user:[EMAIL PROTECTED]:port)
surely, a service is certainly more related to network features than file system's
XML:DB is certainly not the sole resource that deals with services
question : what services people that have a great knowledge of LDAP would find usefull ? is it relevant to have a VFS provider for LDAP ?
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 ?
There exists a ant-task called "org.apache.commons.vfs.tasks.SyncTask".
gotcha !
Not sure, maybe some refactoring needs to be done to use it standalone (without ant).
http://issues.apache.org/bugzilla/show_bug.cgi?id=34859
Misc : I've seen in the Todo list : "Add more selectors: XPath"
Do you plan to contribute it?
why not ?
my Active Tags engine has not yet been released, but all the stuff with VFS works fine with XPath
it would add new dependencies to VFS
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-------------------------------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
