I have looked at this for some time and played with some ideas. Firstly,
I want to say that atm NIO2 sucks. It sucks because there are no decent
provider implementations. So using the knowledge from VFS2 today, I
think a great contribution can be made to "re-use" the VFS2 projects for
NIO2.
I think one can take two routes:
[1] Provide separate providers i.e. fts, sftp etc. which are simply
loaded separately. This has the advantage that each provider can be
developed independently whilst having some core code that is shared. The
core code could include stuff such as caching, which already has some
good solutions in VFS2
[2] Provide a single front-end scheme, which then also loads the
subsequent protocol i.e. vfs:ftp://. This could potentially then just
load up a VFS system underneath and re-use most of the code as-is. I
think there will be quite some technical problems to solve, as I am not
sure whether the current VFS2 architecture will play along being a NIO2
provider (maybe it will, but I don't know).
Unfortunately I have not seen any way to handle multi-scheme such as
zip:http:// in NIO2. It might be possible to do something like that in
route #2.
My gut feeling, is to just start following #1 for now and roll out
separate providers for each protocol. This will allow for some usage
patterns to develop in the community.
On 02/06/2016 00:28, Benson Margulies wrote:
Which direction do you have in mind here? I'd be up for helping to
build a device that makes commons-vfs act as an NIO2 file system
provider, but you might be aiming in the opposite direction.
On Wed, Jun 1, 2016 at 7:02 PM, Peter Ansell <ansell.pe...@gmail.com> wrote:
On 2 June 2016 at 01:48, Mark Fortner <phidia...@gmail.com> wrote:
There was some discussion during the last release about a NIO-compatible
version of VFS. This raised a few questions in my mind.
1. Is there a branch where this work should start?
2. Are there any specific API proposals, if so where are they (or will
they) be documented? Would there be branches with specific proposal code,
or a wiki?
3. Does anyone have an "out of the gate" proposal? A proposed file
system implementation that they're willing to contribute/collaborate on?
Preferably something that's easy to test without additional server setup.
Perhaps a db-based file system that could use java db?
4. How would the code be organized? Would each implementation have to
have its own repo? If so, this might slow down initial API development.
And you always run into the danger that any API changes you make break
implementing code.
5. Has anyone considered support for virtual roots in file system URLs?
Like "home://", "documents://", "music://", etc.
Virtual roots are very simple in NIO2. They are implemented using
FileSystemProvider with a
META-INF/services/java.nio.file.spi.FileSystemProvider file for
autodiscovery by java.util.ServiceLoader.
https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/filesystemprovider.html
Cheers,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r
