My intention since I first saw the NIO stuff before it came out was to replace Commons VFS file system stuff with Java’s but to try to minimize the changes to the existing providers as much as possible. That said, this is surely going to break backward compatibility but that has never been a concern of mine.
I do not think each provider should be in its own repo. Performing a Maven release across multiple repos is a pain and I don’t think each provider should be released independently. I view all the ones we currently have as a core set that people want. I haven’t considered virtual roots. Ralph > On Jun 1, 2016, at 8:48 AM, 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. > > > Cheers, > > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
