Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <0912b235-7c0e-2f2a-1f2a-88116971a577@gmail.com>
References: <CAOwy01tyarYzfWZJt2ggYEL+6VHK0-tPz3S+=Q_-XoJvmZp6GA@mail.gmail.com>
	<CAGYFOCRD9qCFGkZDcixOrQDaAu_d3G6hORHwho0DQuP_tj4ZiA@mail.gmail.com>
	<CALhtWkeZw-dQcLz398QY13+cM6KwesnwDc0_obRsexOVT85BQQ@mail.gmail.com>
	<0912b235-7c0e-2f2a-1f2a-88116971a577@gmail.com>
Date: Wed, 1 Jun 2016 22:17:00 -0700
Message-ID: <CACZkXPxJw9GXYSesDd60yu+RYuwcg+PtCGmFCt-eJYuus+a9QA@mail.gmail.com>
Subject: Re: [VFS] NIO Version Questions
From: Gary Gregory <garydgregory@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a1141b84846a841053444b7a0
archived-at: Thu, 02 Jun 2016 05:17:06 -0000

--001a1141b84846a841053444b7a0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A9" <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 loade=
d
> 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 solution=
s
> 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 thin=
k
> 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 provid=
er
> (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-compatib=
le
>>>> 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/filesyste=
mprovider.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=C3=A9
> Twitter / Ello / Toeter : @ysb33r
>
>

--001a1141b84846a841053444b7a0--