[% setvar title Embed full URI support into Perl %]

This file is part of the Perl 6 Archive

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)