commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
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.

Gary
On Jun 1, 2016 5: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.
>
>
> 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
>
>

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