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