commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ansell <ansell.pe...@gmail.com>
Subject Re: [VFS] NIO Version Questions
Date Thu, 02 Jun 2016 01:39:46 GMT
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 <phidias51@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.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


Mime
View raw message