Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4281F08B.6000208@sophia.inria.fr>
Date: Wed, 11 May 2005 13:46:19 +0200
From: Philippe Poulard <Philippe.Poulard@sophia.inria.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [VFS] questions and suggestions
References: <4280E925.8070101@sophia.inria.fr> <4280F2B9.5020008@ops.co.at>
 <4281C805.4030207@sophia.inria.fr> <4281D934.1020909@ops.co.at>
In-Reply-To: <4281D934.1020909@ops.co.at>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 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&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, 
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: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).

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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org