[% setvar title Embed full URI support into Perl %]
Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Embed full URI support into Perl
Maintainer: Nathan Wiger <nate@wiger.org> Date: 14 Aug 2000 Last-Modified: 16 Sep 2000 Mailing List: perl6-language-io@perl.org Number: 100 Version: 2 Status: Frozen
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.
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 URI::Embed
module as a prototype.
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 "/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 /docs/private
without the
script being changed. This is the way File::Spec
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.
Internally, 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 File::Spec
is
probably suitable.
RFC 36: Structured Internal Representation of Filenames
The CPAN File::Spec
and URI
modules (and upcoming URI::Embed
)