As long as VFS implementations can be successfully plugged in as NIO FileSystemProvider implementations then I don't see any reason not to add that capability in addition to the VFS APIs. Whether or not the public VFS APIs are superceded for most users by the NIO2 APIs, with VFS as a backend, depends on how simple the plugging turns out to be. In either case, VFS won't lose out, as it will still be a pluggable backend for the protocols that it supports.
It would be simpler to transparently support protocols directly, rather than having users choose the file system implementation, in addition to the protocol, in their URIs with a "vfs" prefix. On 2 June 2016 at 10:18, Schalk Cronjé <ysb...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
