Actually FileIO is only somewhat related. It's an interesting proposal. However a quick look shows that vfs only has read-only support for hdfs and I'm not sure it has any support for gcs. Both are often used with Beam. Once vfs supports these filesystems it's worth looking at.
Maybe add to the beam 3.0 hotlidt? On Mon, Mar 5, 2018, 3:26 PM Romain Manni-Bucau <[email protected]> wrote: > Yes (FileIO being the visible part of the FileSystems iceberg ;)). > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > 2018-03-05 19:23 GMT+01:00 Reuven Lax <[email protected]>: > >> I'm confused, as FileIO doesn't seem the same as vfs. Are you maybe >> referring to the filesystem abstraction instead? >> >> On Mon, Mar 5, 2018, 3:19 PM Romain Manni-Bucau <[email protected]> >> wrote: >> >>> Hi guys, >>> >>> What's the rational behind the fileIO impl? >>> >>> Why not using commons-vfs + a pluggable format? Sounds way more open and >>> reusable for end users than a few hardcoded supported formats, no? What's >>> the blocker? If there is a blocker, can't we contribute to [vfs] to make >>> it disappear? >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >> >
