Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
This thread reminded me of something I'd posted a while ago: ---snip--- Date: Wed, 26 Nov 2008 14:23:11 + From: Tim Bunce tim.bu...@pobox.com To: Richard Hainsworth rich...@rusrating.ru, perl6-language@perl.org Subject: Re: Files, Directories, Resources, Operating Systems On Wed, Nov 26, 2008 at 12:40:41PM +0100, Mark Overmeer wrote: We should focus on OS abstraction. [...] the design of this needs to be free from historical mistakes. And avoid making too many new ones. There must be useful prior art around. Java, for example, has a FileSystem abstraction java.nio.file.FileSystem http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileSystem.html which has been extended, based on leasons learnt, in the NIO.2 project (JSR 203: More New I/O APIs for the JavaTM Platform (NIO.2) APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams.) which enables things like being able to transparently treat a zip file as a filesystem: http://blogs.sun.com/rajendrag/entry/zip_file_system_provider_implementation See http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf Tim. p.s. I didn't know any of that when I started to write this look for prior art email, but a little searching turned up these examples. I'm sure there are more in other realms, but NIO.2 certainly looks like a rich source of good ideas derived from a wide range of experience. ---snip--- See http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf plus http://java.sun.com/developer/technicalArticles/javase/nio/ There are many hard-learnt lessons in there that we can benefit from. At the very least the APIs give us things to think about. Tim.
Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
Sounds like a sound generalization to make. bikeshedding On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth rich...@rusrating.ru wrote: This then means that there is an implicit $*FS.connect(); that makes the local system available to the program. mount is the jargon to make a filesystem available, looking backwards, though perhaps connect is more accurate going forwards. /bikeshedding -y
Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
rich...@rusrating.ru wrote:
Would it make sense to define $*FS as the implied local file system, and
thus that a bare 'open' is sugar for
my $fh = $*FS.open('/path/to/directory/filename', :r);
This then means that there is an implicit
$*FS.connect();
that makes the local system available to the program.
I wonder whether this would also be a way of unifying the program interface
for difference Operating Systems, in that a program running on a *nix
machine would have $*FS of type IO::Filesystem::POSIX, while $*FS for a
Windows machine would have type IO::Filesystem::Windows, etc.
Then it would be possible, as Aaron has suggested to have
my $remote-fs = IO::Filesystem::Google.connect(%args);
my $fh = $remote-fs.open($path-or-url, :r);
and then treat $fh as specified elsewhere.
Morover, it would then be possible to do
$*FS = $remote-fs;
I would propose that this sort of flexibility would be useful for programs
that are embedded in other virtual environments, such as browser plugins, or
programs intended to run on thin clients that do not have their own
filesystems.
I like this idea. It's flexible and extendable but has sane defaults.
Leon
Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
On Wed, Jun 30, 2010 at 4:29 AM, Richard Hainsworth rich...@rusrating.ruwrote:
It is normally implied that a program already has a 'local' environment,
including a 'local' filesystem. Thus the syntax
my $fn = open('/path/to/directory/filename', :r) or die $!;
implies a local file sytem.
The idea of an implied local system suggests an implied local environment.
The contents of %*ENV and @*INC seem to be assumed to be local, thought this
is not specified. Given the development of the internet, this is an
assumption I think should be made implicit, as well as the mechanism for
adding remote resources via paths through a network.
Would it make sense to define $*FS as the implied local file system, and
thus that a bare 'open' is sugar for
my $fh = $*FS.open('/path/to/directory/filename', :r);
Yep, that makes perfect sense. Once I have a working VFS object that could
be stored in there, that's probably the best way to go, unless someone
proposes another way between now and then.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
