You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Fortner <ph...@gmail.com> on 2016/06/01 15:48:57 UTC
[VFS] NIO Version Questions
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.
Cheers,
Mark
Re: [VFS] NIO Version Questions
Posted by Ralph Goers <ra...@dslextreme.com>.
My intention since I first saw the NIO stuff before it came out was to replace Commons VFS file system stuff with Java’s but to try to minimize the changes to the existing providers as much as possible. That said, this is surely going to break backward compatibility but that has never been a concern of mine.
I do not think each provider should be in its own repo. Performing a Maven release across multiple repos is a pain and I don’t think each provider should be released independently. I view all the ones we currently have as a core set that people want.
I haven’t considered virtual roots.
Ralph
> On Jun 1, 2016, at 8:48 AM, Mark Fortner <ph...@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.
>
>
> Cheers,
>
> Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] NIO Version Questions
Posted by Mark Fortner <ph...@gmail.com>.
Hi Benson,
While I don't have a strong preference in terms of the approach, my gut
feel is that the adapter approach would force people through additional
layers of VFS code.
Cheers,
Mark
On Wed, Jun 1, 2016 at 4:28 PM, Benson Margulies <bi...@gmail.com>
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.
>
>
Re: [VFS] NIO Version Questions
Posted by Peter Ansell <an...@gmail.com>.
As long as VFS implementations can be successfully plugged in as NIO
FileSystemProvider implementations then I don't see any reason not to
add that capability in addition to the VFS APIs. Whether or not the
public VFS APIs are superceded for most users by the NIO2 APIs, with
VFS as a backend, depends on how simple the plugging turns out to be.
In either case, VFS won't lose out, as it will still be a pluggable
backend for the protocols that it supports.
It would be simpler to transparently support protocols directly,
rather than having users choose the file system implementation, in
addition to the protocol, in their URIs with a "vfs" prefix.
On 2 June 2016 at 10:18, Schalk Cronjé <ys...@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 <an...@gmail.com>
>> wrote:
>>>
>>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
Re: [VFS] NIO Version Questions
Posted by Schalk Cronjé <ys...@gmail.com>.
On 02/06/2016 08:45, Stian Soiland-Reyes wrote:
<snip/>
> As each filesystem provider in nio2 only does one URI scheme we would
> probably need nested URIs or multiple providers.
>
I would like to see how that one will get solved. It is definitely one
of the joys of VFS.
--
Schalk W. Cronj�
Twitter / Ello / Toeter : @ysb33r
Re: [VFS] NIO Version Questions
Posted by Stian Soiland-Reyes <st...@apache.org>.
+1 to go forward with nio-vfs binding.
I have some experience writing a NIO2 FileSystemProvider myself (which
wraps the nio zip support), so I would be willing to join the effort.
As each filesystem provider in nio2 only does one URI scheme we would
probably need nested URIs or multiple providers.
On 2 Jun 2016 6:17 a.m., "Gary Gregory" <ga...@gmail.com> wrote:
> 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é" <ys...@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 <an...@gmail.com>
> >> wrote:
> >>
> >>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
> >
> >
>
Re: [VFS] NIO Version Questions
Posted by Gary Gregory <ga...@gmail.com>.
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é" <ys...@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 <an...@gmail.com>
>> wrote:
>>
>>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
>
>
Re: [VFS] NIO Version Questions
Posted by Mark Fortner <ph...@gmail.com>.
During the push for the last release, it seemed like some of the API
changes were breaking backward compatibility with some of the
implementations. If each implementation resides in its own repo, this would
probably be a recurrent problem, especially if the API is changing
rapidly. Has anyone given any thought to how we would be able to quickly
determine if a change breaks existing implementations?
Also, is there a subset of the Java TCK that could be used to determine
whether we're implementing the APIs consistently?
Cheers,
Mark
On Wed, Jun 1, 2016 at 5:18 PM, Schalk Cronjé <ys...@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 <an...@gmail.com>
>> wrote:
>>
>>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
>
>
Re: [VFS] NIO Version Questions
Posted by Benson Margulies <bi...@gmail.com>.
On Wed, Jun 1, 2016 at 8:18 PM, Schalk Cronjé <ys...@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 <an...@gmail.com>
>> wrote:
>>>
>>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
Re: [VFS] NIO Version Questions
Posted by Schalk Cronjé <ys...@gmail.com>.
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 <an...@gmail.com> wrote:
>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
Re: [VFS] NIO Version Questions
Posted by Benson Margulies <bi...@gmail.com>.
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 <an...@gmail.com> wrote:
> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
Re: [VFS] NIO Version Questions
Posted by Peter Ansell <an...@gmail.com>.
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 <ph...@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 <an...@gmail.com> wrote:
>
>> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
Re: [VFS] NIO Version Questions
Posted by Mark Fortner <ph...@gmail.com>.
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 <an...@gmail.com> wrote:
> On 2 June 2016 at 01:48, Mark Fortner <ph...@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
>
>
Re: [VFS] NIO Version Questions
Posted by Peter Ansell <an...@gmail.com>.
On 2 June 2016 at 01:48, Mark Fortner <ph...@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
Re: [VFS] NIO Version Questions
Posted by Josh Elser <el...@apache.org>.
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?
This is easy enough to create one if there's desire :)
> 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?
Something that would require its own branch to land changes in would be
good to have an outline/overview architecture doc for what the changes
to make are.
> 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.
Seems dependent on the previous point (what exactly are the goals).
> 5. Has anyone considered support for virtual roots in file system URLs?
> Like "home://", "documents://", "music://", etc.
Is this related to the NIO work?
>
> Cheers,
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org