Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

2010-07-02 Thread Tim Bunce
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 w

Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

2010-06-30 Thread Aaron Sherman
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 impli

Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

2010-06-30 Thread Leon Timmermans
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(); > t

Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

2010-06-30 Thread yary
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, t

Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

2010-06-30 Thread Richard Hainsworth
If I might offer a late viewpoint after reading the Aaron's expanded email (attached below). When originally I suggested using 'open' instead of 'connect', the aim was to keep consistency with the paradigm of files on the local system. However, as Aaron's post suggests, when dealing with remo

Re: The obligation of free stuff: Google Storage

2010-06-20 Thread Aaron Sherman
First off, I again have to caution that this thread is conflating "open" with filesystem interaction. While open is one of many ways of interacting with a filesystem, it isn't even remotely sufficient (nor my immediate focus). One can ask for and modify filesystem metadata, security information, an

Re: The obligation of free stuff: Google Storage

2010-06-20 Thread C.J. Adams-Collier
On Thu, 2010-06-10 at 21:17 -0400, Brandon S. Allbery KF8NH wrote: > On Jun 10, 2010, at 07:22 , Leon Timmermans wrote: > > I agree it should be similar to normal FS interactoin to make matters > > as intuitive as possible, but I horrified by the idea of overloading > > open() that way. That's a P

Re: The obligation of free stuff: Google Storage

2010-06-17 Thread Kevan Benson
On 06/10/2010 05:07 AM, Mark J. Reed wrote: On Thursday, June 10, 2010, Leon Timmermans wrote: I agree it should be similar to normal FS interactoin to make matters as intuitive as possible, but I horrified by the idea of overloading open() that way But open is already overloaded in p5, with

Re: The obligation of free stuff: Google Storage

2010-06-11 Thread Leon Timmermans
On Thu, Jun 10, 2010 at 2:07 PM, Mark J. Reed wrote: > But open is already overloaded in p5, with pipes etc.  We don't want > to repeat the mistakes of the past, and the fact that open(FH, $foo) > could run an arbitrary shell command was arguably a mistake, but > transparent access to storage wher

Re: The obligation of free stuff: Google Storage

2010-06-10 Thread Brandon S. Allbery KF8NH
On Jun 10, 2010, at 07:22 , Leon Timmermans wrote: I agree it should be similar to normal FS interactoin to make matters as intuitive as possible, but I horrified by the idea of overloading open() that way. That's a PHP mistake I wouldn't like seeing repeated. If you want open to do something tha

Re: The obligation of free stuff: Google Storage

2010-06-10 Thread Mark J. Reed
On Thursday, June 10, 2010, Leon Timmermans wrote: > I agree it should be similar to normal FS interactoin to make matters > as intuitive as possible, but I horrified by the idea of overloading > open() that way But open is already overloaded in p5, with pipes etc. We don't want to repeat the mi

Re: The obligation of free stuff: Google Storage

2010-06-10 Thread Leon Timmermans
On Thu, Jun 10, 2010 at 9:15 AM, Richard Hainsworth wrote: > Ideally [at least, what I would like], managing a file on a remote resource > should be the same as managing one locally, eg. > > my Amazon $fn = open("$path-to-input-file-location/$file-name", :r) or die > $!; > for $fn.readlines { }; >

Re: The obligation of free stuff: Google Storage

2010-06-10 Thread Richard Hainsworth
Ideally [at least, what I would like], managing a file on a remote resource should be the same as managing one locally, eg. my Amazon $fn = open("$path-to-input-file-location/$file-name", :r) or die $!; for $fn.readlines { }; $fn.close; my Google $fn = open("$path-to-output-file-location/$fil

Re: The obligation of free stuff: Google Storage

2010-06-09 Thread Aaron Sherman
On Wed, Jun 9, 2010 at 10:04 AM, Aaron Sherman wrote: > Has anyone begun to consider what kind of filesystem interface we want > for things like sftp, Amazon S3, Google Storage and other remote > storage possibilities? Is there any extant work out there, or should I > just start spit-balling? In

The obligation of free stuff: Google Storage

2010-06-09 Thread Aaron Sherman
On a lark, I submitted a request to Google for membership in the Google Storage beta on the basis of doing something virtual filesystemish for Perl 6. The bastards gave me an account, so now I feel as if I should do something. Has anyone begun to consider what kind of filesystem interface we want