commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [VFS] NIO Version Questions
Date Thu, 02 Jun 2016 00:55:28 GMT
On Wed, Jun 1, 2016 at 8:18 PM, Schalk Cronjé <ysb33r@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.peter@gmail.com>
>> wrote:
>>>
>>> On 2 June 2016 at 01:48, Mark Fortner <phidias51@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message