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 con
On 02/06/2016 08:45, Stian Soiland-Reyes wrote:
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 / E
+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
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é" wrote:
> I have looked at this for some time and
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 i
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
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
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
wrote:
> Which direction do you have in mind here? I'd b
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, depen
On Wed, Jun 1, 2016 at 8:18 PM, Schalk Cronjé 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 contributi
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
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 wrote:
> On 2 June 2016 at 01:48, Mark Fortner wrote:
>>
On 2 June 2016 at 01:48, 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?
>2. Are there any specific API proposals, if so where are
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
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
15 matches
Mail list logo
