> Pick one:
>
> 1) Filenames that end with a '/' are directories and those that don't
> are files. (Both examples are files.)
No, too restrictive. I don't like this and would hate having to remember
it.
> 2) Filenames are tested to determine how they are to be opened. (C<-f
> '/etc'> is false on my system, but C<-d '/etc'> is true, therefore it is
> a directory. '/etc/motd' is a file on my system since -f returns true
> and -d returns false.)
Better, definitely helps out making things easier. But what if the path
doesn't exist yet and you're trying to write to it? Assume it's a file?
> The single argument open using URLS is a stable, standard interface to
> all sorts of files. Quoting from <http://www.w3.org/Addressing/>:
First off, I'm not anti-URI at all. I just want to be able to use both
ways if we support URIs.
Here's a step-by-step process for supporting both that I propose.
Suggestions welcome:
1. If called as an indirect object function (in the form currently
proposed), steps 2-3 are skipped and the handler specified is
automatically invoked.
2. The top-level open() looks to see the file is a valid URI, namely:
[method] :// [resource]
If so, method becomes the handler, the :// is stripped, and the rest
is passed to the handler. If no handler by that name has been
registered, undef is returned.
3. If no handler was found (the path was not a URI), then the default
'file' handler is used.
4. The handler's open is called. Any special operations are done by
the individual handler. For example, the 'file' handler might be
equipped to auto-determine if something is a directory and, if so,
fork the 'dir' handler. The handler's open returns a fileobject
or undef.
This should probably be represented by a flowchart, but that's hard in
ASCII. :-)
Is this is ok, the next version will include it.
-Nate
