On Wed, Jun 1, 2016 at 8: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.
OK, seems simple enough, one JIRA per provider. > > > > 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
