commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yannick Menager" <ymena...@yahoo.co.uk>
Subject Re: [VFS] Contributions to the project
Date Fri, 09 Dec 2005 11:50:38 GMT

On Fri, 09 Dec 2005 11:12:44 +0000, "Yannick Menager"
<ymenager@yahoo.co.uk> said:
> On Thu, 08 Dec 2005 19:54:13 +0100, "Mario Ivankovits" <mario@ops.co.at>
> said:
> > > 3) File Actions
> > >   
> > There is already a conribution which achieves this. Attached to 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN 
> > access) it waits to have VFS release 1.0 out.
> > Such an interface will be used to e.g. commit/update a file, retrieve a 
> > thumbnail or exif data (in case of an image format wich allows it)
> 
> I've had a look at it, but i didn't like the fact that retrieving the
> services is tied up to the java Class (i.e.: FileService
> getService(Class serviceClass) ).
> 
> The reason i don't like that approach, is that one of the things i'm
> planning to do, is a 'remote VFS' provider. That provider would not only
> send the information about the files, but also provide the list of
> actions that can be executed on each file, and allow the client VFS to
> remotely invoke those actions. In order to do that with that API, it
> would require the actually classes for all services to be in the
> client's classpath, which is a very bad approach. My idea is to have the
> base API to provide enough information to cover most basic use cases,
> and off course specific implementations of the service can provide
> richer API that the user of the API can make use.

Ok, i've put in an initial draft on my svn server at
http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/action/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message