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 11:46:19 GMT
Mario Ivankovits wrote:
> 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 parser ?
> Ok, it might be possible, but then again 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

done :

>>>> 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 ?
> 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, 
(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:pwd@host: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).

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

           (. .)
|   Philippe Poulard    |

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

View raw message