[TransWarp] Testing Help Needed: URL contexts

[Phillip J. Eby]

At 06:40 AM 5/20/03 +0300, alexander smishlajev wrote:
>Phillip J. Eby wrote:
>>
>>>>I just checked in a replacement for the old URL parsing mechanisms in 
>>>>PEAK, and I could really use some help with validating that the 
>>>>existing supported schemes are parsed correctly by the current CVS 
>>>>version of PEAK.
>>>
>>>FileURL does incorrectrly handle relative paths.
>>Technically, a relative path is not a valid 'file:' URL
>
>isn't it?  as far as i understand rfc 1808, 'file:egg;trim?warning#body' 
>is perfectly valid relative url.

Interesting.  My sources were RFC 1738 and RFC 2396.  I'll check out 
1808.  To be honest, I don't remember whether what I read said you musn't 
use them, but I do remember them saying it didn't make sense to put a 
scheme on a relative URI.


>>The correct mechanism for relative paths to use is a relative URI, not a 
>>schemed URI.  In other words href="./egg?warning" is a valid relative URI 
>>href, but href="file:./egg?warning" is invalid.
>
>then, how will it be possible to specify a 'logfile:' (or 'lockfile:', or 
>any other file-related) scheme?

With an absolute path.  I really don't want to support relative paths in 
those kinds of URLs.

The problem is that 'file:' syntax is ambiguous, as I found when I tried to 
write a correct parser.  Either you must force all file URLs to begin with 
'//', optional hostinfo, '/', (which means only absolute paths), or you 
must resort to heuristic trickery to "guess" what the URL means in ways 
that have nothing to do with the specifications.  :(

If there is sufficiently strong demand for relative filenames -- and I'm 
not yet sure there is -- the solution would be to make 'logfile', 
'lockfile', etc. work the way 'zconfig.schema' does.  That is, the body is 
treated as a relative filename and converted to an absolute one, unless it 
has a scheme prefix, in which case it's handled as a URL of that 
scheme.  Then, the resulting body URL is opened and adapted to the type 
denoted by the outer scheme.  IOW, the body is looked up, and then the URL 
wraps a log or lockfile instance around the resulting item.

I guess I should add this to the a3 todo list; I really don't want to mess 
with it for a2.  I'd like to get a2 out the door quickly to fix all the a1 
problems, including the broken source distribution.