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 > >
