Re: [FileAPI] Length of the opaque string for blob URLs

There is no requirement for that in the spec/draft, it's useful for our
implementation.

On Fri, Dec 16, 2011 at 3:06 PM, Charles Pritchard <chuck@jumis.com> wrote:

> Is there something requiring that the origin be part of the URL?
>
>
>
> On Dec 16, 2011, at 2:29 PM, Michael Nordman <michaeln@google.com> wrote:
>
> > "and MUST be at least 36 characters long"
>
> I can't think of any reason for that requirement, seems fine to delete it.
>
> Webkit and Chrome do use guids but also embed the origin in these url.
>
>
> On Fri, Dec 16, 2011 at 5:58 AM, Jarred Nicholls < <jarred@webkit.org>
> jarred@webkit.org> wrote:
>
>> On Fri, Dec 16, 2011 at 6:27 AM, Anne van Kesteren < <annevk@opera.com>
>> annevk@opera.com> wrote:
>>
>>> On Fri, 16 Dec 2011 12:21:34 +0100, Arun Ranganathan <<aranganathan@mozilla.com>
>>> aranganathan@mozilla.com> wrote:
>>>
>>>> Adrian: I'm willing to relax this.  I suppose it *is* inconsistent to
>>>> insist on 36 chars when we don't insist on UUID.  But I suspect when it
>>>> comes time to making blob: a registered protocol (it was discussed on the
>>>> IETF/URI listserv), the lack of MUSTs will be a sticking point.  We'll take
>>>> that as it comes, though :)
>>>>
>>>
>>> I do not really see why Chrome cannot simply use UUID as well. It's not
>>> exactly rocket science. It seems that is the only sticking point to just
>>> having the same type of URLs across the board.
>>
>>
>> The consistency and predictability of having UUIDs across the board could
>> prove useful.
>>
>>
>>>
>>>
>>>
>>> --
>>> Anne van Kesteren
>>>  <http://annevankesteren.nl/>http://annevankesteren.nl/
>>>
>>>
>>
>