Re: RFC 100 (v2) Embed full URI support into Perl
I'd rather see you drop (or footnote) the discussion of how the various systems are going to map content among themselves, and focus more on what the construct allows. For instance, returning to some of the original implementation ideas, that the location information be passed to the protocol handler, which will then DWIM, as determined by the platform, protocol, etc, etc. Getting DOS and Unix to look at a portable construct. Sure. Needed, one way or another. Getting them to Do The Right Thing based a single, uberportable input string just ain't gonna happen, so I'd address that either separately (with the file:// implementation) or not at all. Something tells me you should have written this RFC. ;-) Great points, I'll have to unfreeze this and redo it. Thanks. One of the big draws (to me) for URI support isn't even mentioned in the RFC, although it was discussed following v1, and that is adding DWIMmery to the open to support more than files and pipes. (We recently added URI support to one of our projects for this reason.) Check out RFC 14. At the bottom it talks all about this. However, I'm going to add this into here as well because y'know, it's probably the place it should really be. -Nate
Re: RFC 100 (v2) Embed full URI support into Perl
On Sun, Sep 17, 2000 at 05:36:56AM -, Perl6 RFC Librarian wrote: unlink "/local/etc/script.conf";# non-portable unlink "file:///local/etc/script.conf"; # portable '/local/etc/script.conf' is very unlikely to exist or be a sensible filename on Windows or MacOS (or Unix. Shouldn't that be /usr/local?). The suggestion about stripping C:\ off the filepath doesn't help much. Windows programs like to put things in the root directory. (C:\PERL anyone?). Unix prefers many different locations, and severely restricts usage of /. MacOS and Windows paths have a chance of being portable, since both don't mind putting things in root positions, by mapping C: to the main MacOS partition. What about D:? "file://C|/foo" and "file://D|/foo". On Windows they're seperate. On Unix they're... what? On MacOS, C: could be the main partition and D: a secondary one (if it exists, which is relatively uncommon), but which one? And as the disposition of MacOS partitions varies wildly, it will more than likely produce extremely surprising results. AUUGH!! And we haven't even gotten into VMS and OS/2 yet. Oh, how about the Amiga? BeOS? OS390? Solving the file seperator problem is one thing. Calling it "portable" is huge stretch. Now, where the file: url *does* win is relative files. open 'file:some/directory/file'; All the noise I was talking about above goes away.. but there's more trouble waiting. Case-sensitive vs insensitive filesystems, maximum filename length, maximum path length, restrictions on the filename, restrictions on the suffix (ie. 8.3 DOS). Maybe we should just go back to paper. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRn scHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: RFC 100 (v2) Embed full URI support into Perl
On Sun, 17 Sep 2000, Nathan Wiger wrote: The only comments received were on my crappy examples, which have been clarified. Well, sort of. More comments on "crappy" examples. :-) The key syntax benefit is #1. This lets us use URIs in any function to allow scripts that can be used on many platforms simultaneously: $fo = open 'C:\docs\private'; # non-portable $fo = open 'file://C|/docs/private';# portable unlink "/local/etc/script.conf";# non-portable unlink "file:///local/etc/script.conf"; # portable If portability is not a concern, then scripts can be written using the familiar, native syntax. Otherwise, all Perl funcs should be able to accept URIs so that writing portable programs is simple. Many asked "Hey, how are those two any more portable? The drive letter is still in there." Good point. I would argue that this is where Perl should DWIM. For example, if a script doing this: There's a big difference between construct-portable and content-portable. Content-portable is, IMHO, not Perl's responsibility. We only need to address construct-portable. Given that, the above are still "crappy" examples because you're trying to address both. It detracts from the actual idea you're proposing. (As you may have noticed from several posts. Michael Schwern's recent post on the subject is a good example.) I'd rather see you drop (or footnote) the discussion of how the various systems are going to map content among themselves, and focus more on what the construct allows. For instance, returning to some of the original implementation ideas, that the location information be passed to the protocol handler, which will then DWIM, as determined by the platform, protocol, etc, etc. Getting DOS and Unix to look at a portable construct. Sure. Needed, one way or another. Getting them to Do The Right Thing based a single, uberportable input string just ain't gonna happen, so I'd address that either separately (with the file:// implementation) or not at all. One of the big draws (to me) for URI support isn't even mentioned in the RFC, although it was discussed following v1, and that is adding DWIMmery to the open to support more than files and pipes. (We recently added URI support to one of our projects for this reason.) -- Bryan C. Warnock ([EMAIL PROTECTED])
