Re: RFC 100 (v2) Embed full URI support into Perl
Chaim Frenkel <[EMAIL PROTECTED]> writes: > > "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: > > NC> $htdoc = open uri "http://www.yahoo.com" or die; with uri in the > NC> standard library and also make it easy to stack the module that > NC> does uri at the top of 'file' so that the default is to call the > NC> uri stuff. > > Is it just me, but I keep wondering how Uri Guttman gets into this. He gets everywhere. Didn't you realise? -- Piers
Re: RFC 100 (v2) Embed full URI support into Perl
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: NC> $htdoc = open uri "http://www.yahoo.com" or die; NC> with uri in the standard library NC> and also make it easy to stack the module that does uri at the top of 'file' NC> so that the default is to call the uri stuff. Is it just me, but I keep wondering how Uri Guttman gets into this. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 100 (v2) Embed full URI support into Perl
On Mon, Sep 18, 2000 at 08:26:26AM -0700, Nathan Wiger wrote: > Hildo Biersma wrote: > > > > > Personally I hated it. And I distinctly remember saying so. And I > > > still hate it. > > > > I dislike it too. URIs are a user-space matter and should not be > > built-in to the language - put it in a module. And if you have an OS > > that implements URIs directly, well then that module becomes really > > simple :-) > > I'm not sure that URIs are a user-space matter. They're a widely > accepted portable standard for spelling out resource locations. They > also make this: > >$htdoc = open "http://www.yahoo.com" or die; > > Natively possible, without bloating the language. See RFC 14 for how > this could work. Should they go into the core? Or should I register a URI handler to go $htdoc = open uri "http://www.yahoo.com" or die; with uri in the standard library and also make it easy to stack the module that does uri at the top of 'file' so that the default is to call the uri stuff. This would keep the core smaller, but let any script that wants it get "builtin" URIs with only one line. RFC 14 is frozen, otherwise I'd suggest that the default handler isn't 'file' but 'magic' or 'perl' - ie something that knows about | for pipes, & for dup'ing, |- for forking and soforth. 'file' could then be a vanilla always-opens-a-file handler. Nicholas Clark
Re: RFC 100 (v2) Embed full URI support into Perl
Hildo Biersma wrote: > > > Personally I hated it. And I distinctly remember saying so. And I > > still hate it. > > I dislike it too. URIs are a user-space matter and should not be > built-in to the language - put it in a module. And if you have an OS > that implements URIs directly, well then that module becomes really > simple :-) I'm not sure that URIs are a user-space matter. They're a widely accepted portable standard for spelling out resource locations. They also make this: $htdoc = open "http://www.yahoo.com" or die; Natively possible, without bloating the language. See RFC 14 for how this could work. Many other languages (like PHP) support URIs natively. It makes many things easier. -Nate
Re: RFC 100 (v2) Embed full URI support into Perl
Hildo Biersma <[EMAIL PROTECTED]> writes: > > > =head1 NOTES ON FREEZE > > > > > > The only comments received were on my crappy examples, which have been > > > clarified. Everyone seemed to like the idea. > > > > Personally I hated it. And I distinctly remember saying so. And I > > still hate it. > > I dislike it too. URIs are a user-space matter and should not be > built-in to the language - put it in a module. Indeed. I respectfully submit that this particular RFC be moved to perl6-stdlib (and doctored slightly to make it work there...) -- Piers
Re: RFC 100 (v2) Embed full URI support into Perl
> > =head1 NOTES ON FREEZE > > > > The only comments received were on my crappy examples, which have been > > clarified. Everyone seemed to like the idea. > > Personally I hated it. And I distinctly remember saying so. And I > still hate it. I dislike it too. URIs are a user-space matter and should not be built-in to the language - put it in a module. And if you have an OS that implements URIs directly, well then that module becomes really simple :-) Hildo
Re: RFC 100 (v2) Embed full URI support into Perl
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Embed full URI support into Perl > > =head1 VERSION > > Maintainer: Nathan Wiger <[EMAIL PROTECTED]> > Date: 14 Aug 2000 > Last-Modified: 16 Sep 2000 > Mailing List: [EMAIL PROTECTED] > Number: 100 > Version: 2 > Status: Frozen > > =head1 ABSTRACT > > Currently, Perl does not natively support URIs. It would be really cool > if it did, since this would make writing and maintaining portable > programs a breeze. > > =head1 NOTES ON FREEZE > > The only comments received were on my crappy examples, which have been > clarified. Everyone seemed to like the idea. Personally I hated it. And I distinctly remember saying so. And I still hate it. -- Piers
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, 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])
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 ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRn scHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
RFC 100 (v2) Embed full URI support into Perl
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Embed full URI support into Perl =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 14 Aug 2000 Last-Modified: 16 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 100 Version: 2 Status: Frozen =head1 ABSTRACT Currently, Perl does not natively support URIs. It would be really cool if it did, since this would make writing and maintaining portable programs a breeze. =head1 NOTES ON FREEZE The only comments received were on my crappy examples, which have been clarified. Everyone seemed to like the idea. I am currently developing the Perl 5 C module as a prototype. =head1 DESCRIPTION Full URI support gives us several benefits: 1. It allows easy authoring of portable scripts 2. It is a stable and well-established standard 3. It is easily recognizable and very web-friendly 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: $fo = open 'file://C|/docs/private'; Is run on a UNIX box, Perl should be able to realize that it's currently on a UNIX machine and say: 1. Ok, lose the drive letter and '|', that's useless 2. Our file separator here is '/', so let's do this! Then it would contruct the correct path of C without the script being changed. This is the way C works, basically. The goal of this proposal is to get the same effect by using URIs, which are more commonly used and understood, and easier to work with since they can be passed around as simple strings. =head1 IMPLEMENTATION B, URIs and native filenames should be converted into a third, different representation. This allows for the easy conversion back and forth between them. For example, URIs could be converted to native filenames and then the native filenames passed to the actual functions. Indeed, this is the way URIs generally work. The internal representation of Perl filenames is covered in RFC 36 and is beyond the scope of this RFC. Something akin to C is probably suitable. =head1 REFERENCES RFC 36: Structured Internal Representation of Filenames http://www.mail-archive.com/perl6-language-io@perl.org/msg00096.html http://www.mail-archive.com/perl6-language-io@perl.org/msg00117.html http://www.w3.org/Addressing/ The CPAN C and C modules (and upcoming C)
