Re: IPv6 addresses / uriGetter encoding

On Jun 23, 2010, at 3:39, Thomas Leonard wrote:

> So, I guess the clean thing is for the lexer to expand %XX and for
> <http> to re-escape for HTTP and for <file> to modify for the  
> filesystem
> on Windows (as it's doing already).

The lexer cannot expand %hh, because they escape special characters,  
not just disallowed ones. <http://example.com/a=b&c=d%26e> is  
different from <http://example.com/a=b&c=d&e>.

Looking at the local filesystem case is misleading because filesystems  
do not generally provide ways to

> ? <file:%20>.getText()
> # problem: <FileNotFoundException: /home/tal/%20 (No such file or  
> directory)>
>
> ? <file: >.getText()
> # syntax error:
> #   file: >.getText()
>
> It seems obvious that <file:someDir>["%20"] should interpret this is a
> file called "%20", not a file called " ". The case for <file>["%20"]  
> is
> less clear (I guess this is why Kevin wants to use separate objects).

It is my opinion that if we're going to use URL notation, we had  
better use URL syntax, and <file:///%20> means the file named unixly  
"/ ", and if you want something else you had better not use angle  
brackets and colons.

I agree that the issue of what "get" should mean is in general not  
clear.

Hm.

Complicated option: the <a:b> notation expands to, not
   <a>["b"]
but
   <a>[makeURLText("b")]

That is, we still use get/1, but label the key being looked up as  
being not a String but a URLText, which is just a String wrapped in a  
distinct type (which coerces to String so such distinctions can be  
ignored when desired). Then all filesystem lookups can treat URLText  
as %20 -> " " but treat String literally.

I rather like this idea I just invented: it is a marginal step away  
from the hazards of untyped string data and what-escaping-level-is- 
this. But it might be too arcane for users. Thoughts?

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>