+1 to go forward with nio-vfs binding. I have some experience writing a NIO2 FileSystemProvider myself (which wraps the nio zip support), so I would be willing to join the effort.
As each filesystem provider in nio2 only does one URI scheme we would probably need nested URIs or multiple providers. On 2 Jun 2016 6:17 a.m., "Gary Gregory" <garydgreg...@gmail.com> wrote: > I think we should do it all! :-) > > Starting with making all of VFS a nio2 provider. Then we can do one-offs > for each file type as we go. It then should be possible to offer a more > light weight solution. > > Gary > On Jun 1, 2016 5:18 PM, "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 > > > > >
