Mario Ivankovits wrote:
For the next version of VFS I'll rework the cache. What I will do is to remove the cache at all and allow to decorate a FileObject with a e.g. CachedFileObject (or so), then for sure we will have methods as you described, though, it should be possible to use VFS without having to deal with a cache at all. This might lead to performance loss, but the user can decide what he/she would like to have:

*) Refresh cache on demand (as is)
*) Refresh cache after resolveFile()
*) Refresh cache before any file operation
Sounds good.
2) VFS Browser

An windows explorer type panel to browse a VFS
There is alread jcommander. They started to adapt it to use VFS. Though having a method to extend the default swing "open file" dialog would be nice.
I'll have a look, depends on how tighly integrated with the 'filesystem'
concept. My idea for the browser is for it to be completely abstracted
out of it ( so all it's 'actions' would come from the Action/Service
framework ), and the 'Views' would be provided by plugins.
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)
Yes that looks like that might do the job. However one of my
requirements is for the service framework to be able to be used
exclusively with the API, without requiring code to handle it's
different type of services... So basically i want the browser to be able
to display the different actions that can be done on a file when you
right-click on the file, and allow to execute that action, dynamically
building an 'parameter' panel ( unless off course there is a plugin to
especially support the Action/Service.

Also, another concept i needed was Action/Service that are done from one
file to the other ( for drag & drop support )

Said that, if you would like to jump into VFS development there is still enough room, please have a look at: http://wiki.apache.org/jakarta-commons/VfsNext
The areas that i'm going to be mostly interested will indeed be the
Service API, aspects.

Oh, and one idea you might want to add to the list, a special
classloader that would dynamically transform all usage of java.io.File
to use VFS instead, so that any application could be VFS-enabled. ( I
might implement that if i have time )


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to