> 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.
Something tells me you should have written this RFC. ;-)
Great points, I'll have to unfreeze this and redo it. Thanks.
> 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.)
Check out RFC 14. At the bottom it talks all about this. However, I'm
going to add this into here as well because y'know, it's probably the
place it should really be.
-Nate
