Re: [File API] opaque string

On 9/29/11 12:29 PM, Anne van Kesteren wrote:
> On Thu, 29 Sep 2011 01:19:53 +0200, Arun Ranganathan 
> <arun@mozilla.com> wrote:
>> On 8/31/11 3:45 AM, Anne van Kesteren wrote:
>>> Yeah sure, every URI is an IRI, but that is not what I am asking.
>>
>> I'm sorry, I think I'm not understanding you very clearly :(  The 
>> spec. currently specifies what can be an opaque string for blob: 
>> URIs.  Also, the spec. says that special characters (e.g. "#") should 
>> be escaped, so that the fragment isn't confused with characters in 
>> the opaque string production.  Other special characters should be 
>> escaped as well.  What problem have you identified with this, and 
>> what should we be doing instead to solve it?
>
> "#" is a special character. However, e.g. "ΓΌ", is not. Requiring 
> characters that are allowed in IRIs to be escaped serves no purpose as 
> far as I can tell.

A good candidate for the URI listserv is the UUID; in defining the 
repertoire for opaque string, initially pushing for UUID itself met with 
some resistance from the Chrome team, so I've allowed a more expansive 
charset, and allow for other characters, modulo them being escaped.  
This doesn't seem to be too restrictive.  Is there a use case you have 
in mind that finds UUID too restrictive, for instance, or are you able 
to supply a use case that requires a larger set of (unescaped) 
characters, including IRI characters?

Bear in mind that the main use case for opaque string is unique 
identifier, NOT shared across the web, and that uniquely identifies an 
"in-memory" resource that has a pretty defined lifetime.  Everything 
else is honestly just gravy, unless you are able to cough up a use case 
that gives us all collective pause.  I'll gladly change it if you can do so.

-- A*

Received on Thursday, 29 September 2011 18:12:22 UTC