Hi Mark, It may or may not be that heavyweight a process. It all depends on the way it is implemented. One reason for virtual roots could be to extract the operating system specific aspects away if possible.
However, I don't see people wanting "home" or "Photos" as urgently as supporting common internet protocols as virtual file system roots. I was thinking that to start off with the existing VFS providers could each be mapped as NIO2 FileSystemProvider implementations. For example, it would be great as an experiment to have the VFS implementation of "sftp" supported using NIO2. After there is experience supporting that workflow VFS could move on to support operating system abstractions for home/photos/documents/etc., but not necessary initially to get experience with the way the integration will work. One big question that is outstanding is whether it can be implemented in a simple way so that the NIO2 APIs, Files/Path/etc. alone could be used to operate it, based on java.util.ServiceLoader finding the VFS implementation to eliminate all VFS specific APIs from user programs, or whether the user would still need to configure VFS manually first before using NIO2. Cheers, Peter On 2 June 2016 at 11:24, Mark Fortner <phidia...@gmail.com> wrote: > Hi Peter, > Implementing a new file system just to support "home" or "Photos" virtual > roots, would be a rather heavyweight approach for something that should be > configurable. Each operating system (and OS version) could have different > mappings for these roots. > > Cheers, > > Mark > > > On Wed, Jun 1, 2016 at 4: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
