Re: RFC 14 (v3) Modify open() to support FileObjects and

[email protected] (Nathan Wiger)  wrote on 12.08.00 in <[email protected]>:

> 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.

Bad. Not all URIs follow that syntax. (Think mailto: or news:, for  
example.) There's also scheme-less relative URIs, but let's not go there.

Of course if you just look at the ":", you get in trouble with everything  
that can have a : in the filename.

So I think a better way would be:

 2. The top-level open() looks to see the file looks like an URI, namely:

         ($scheme, $scheme_specific_part) = /^([a-z][a-z0-9.+-]*):(.*)$/i

and if there is a registered handler for (lc $scheme).

    If so, (lc $schene) becomes the handler, and $scheme_specific_part
    is passed to the handler.

For details on URI syntax, see (IETF) RFC 2396, and yes, case *is*  
insignificant in URI schemes. Note that drive letters (and many MacOS  
volume names) are followed by ":" and thus *do* look like URI schemes,  
this is why the above tests for a registered handler. (You can register 26  
default handlers under Windows/DOS, but I trust you don't want to register  
a default handler per mounted MacOS volume. And then there are filenames  
like "LPT1:" ... please let's not go there.)

I might note in passing that I have a web mirroring application that uses  
Web URLs as-is as Unix filenames, yielding directories named "http:" and  
"ftp:". I'd obviously need to explicitely disambiguate this.

There's also the current < +> etc. syntax. Do we want to do something  
about it? What?

> 3. If no handler was found (the path was not a URI), then the default
>    'file' handler is used.

Well, maybe not. The syntax of file: URIs is not (necessarily) exactly the  
same as that of native filenames, so maybe this should not be the same  
handler. (Look at DOS/Windows filenames for pretty obvious examples. Then  
there are % escapes.)

But this is only a nit.

> 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.

I have the uncomfortable feeling that somewhere, out there, we'll hit a  
filesystem that can have files and directories with exactly identical  
names. Especially as Linus was just seen writing in support of that idea  
on the linux-kernel mailing list.


MfG Kai