commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [VFS] NIO Version Questions
Date Thu, 02 Jun 2016 05:17:00 GMT
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.

On Jun 1, 2016 5:18 PM, "Schalk Cronjé" <> 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 <>
>> wrote:
>>> On 2 June 2016 at 01:48, Mark Fortner <> 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.
>>> Cheers,
>>> Peter
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message