During the push for the last release, it seemed like some of the API changes were breaking backward compatibility with some of the implementations. If each implementation resides in its own repo, this would probably be a recurrent problem, especially if the API is changing rapidly. Has anyone given any thought to how we would be able to quickly determine if a change breaks existing implementations?
Also, is there a subset of the Java TCK that could be used to determine whether we're implementing the APIs consistently? Cheers, Mark On Wed, Jun 1, 2016 at 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 > >
