Am 09.10.2013, 21:53 Uhr, schrieb Mark Fortner <phidia...@gmail.com>:
Hi Bernd,
I'm a user rather than a developer of VFS. I have a weekend project to
create a file browser in JavaFX. Prior to that I wrote an NFS provider
for
a company I was working for.
Thats nice, is it available somewhere?
Concurrency/thread safety should definitely be a priority. Part of my
weekend project uses a threadpool to handle a variety of different types
of file operations.
If there was an adapter that could adapt VFS2 calls to NIO2 calls that
would be nice. But I think that rewriting all of the current providers
to
make them NIO2 providers would be a bit of a stretch.
Yes, I think one of the first things would be to have an
FileSystemProvider Adapter which can present a VFS root to NIO.2.
...
Metadata support would also be useful:
http://apache-commons.680414.n4.nabble.com/vfs-File-Metadata-td739249.html
I was thinking this could be done with file attributes. Maybe define a
fixed set of well known attributes like "file.lastaccessed" "file.mode"
etc. But the discussed approach with own interfaces is also an option.
Plugin download support would also be useful. One of the current
problems
that most users face is that the available file systems aren't
downloadable
from a single point. So if you encounter a URL that requires a different
provider, you have to hunt around for the provider and manually install
it.
Yes, maybe in combination with dependency injection or OSGi...
It would be useful VFS could simply check a registry of providers, and
download the appropriate provider. It would keep the core download
fairly
small and make it easy for 3rd party providers to be used.
I would not do that in the VFS core, but a nice thing would be to have an
listener which gets requests for schemes/filetypes and can do the provider
registering. You can then provide a "RegistryResolver" listener who can be
used in interactive projects.
The biggest challenge for most 3rd party developers is finding a way to
do
automated testing without installing a file system to test with. It
would
be interesting to find out how the NIO2 file system developers are
testing
their providers.
With the JDBC provider I have used H2 and Derby, that worked fine (however
I had to copy the test resources into my project which I want to avoid).
With the digest archive filesystem I have the problem that the filesystem
behaves rather untypical so I am not sure if the capability based approach
to configure the tests to run will be enough - but yes thats a topic I
will open up a seperate thread later.
Anyway, his is all probably more than you were asking for, but I hope
this
helps.
Thanks for the feedback :)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
