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
To: Richard Hainsworth , 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]
On Wed, Jun 30, 2010 at 4:29 AM, Richard Hainsworth wrote:
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
Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
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]
Sounds like a sound generalization to make. On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth 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. -y
