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 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,

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

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. 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

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 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

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 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

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 PHP

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, and

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 Timmermansfaw...@gmail.com 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

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 markjr...@gmail.com 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

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 =

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 rich...@rusrating.ru 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

Re: The obligation of free stuff: Google Storage

2010-06-10 Thread Mark J. Reed
On Thursday, June 10, 2010, Leon Timmermans faw...@gmail.com 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

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

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 a...@ajs.com 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