Re: URLs into IndexedDB databases

On Thu, Jul 18, 2013 at 6:58 AM, Kornel Lesiński <kornel@geekhood.net> wrote:
> On Mon, 15 Jul 2013 09:57:30 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>
>>
>> indexeddb:<origin>/<persistence>/<database>/<objectStore>/<index>/<key>/<keypath>
>>
>> Each piece above would have to be encoded such that it contains only
>> valid, non-'/', URL characters. For things like database name and
>> objectStore name this is easy by simply %-encoding characters.
>>
>> For the key this is significantly messier. We have to encode things
>> like Dates and numbers, as well as Arrays. There's no shortage of ways
>> of doing this, but there's no particularly clean way to do it either I
>> think.
>
>
> That makes sense and I think key encoding is solvable with some microsyntax
> (I'll refrain from bikeshedding it here :)
>
>
> But what these URLs will be used for? Probably not for simple values that
> are smaller than the URL itself (what can you do with a URL that points to
> an integer?)
>
> So maybe the key use-case will be linking to Blobs in indexedb (e.g. images,
> full documents) and then it would suffice if only those Blobs had permanent
> URLs (e.g. window.URL.createObjectURL would be permanent for stored blobs).

I think loading blobs is the main use case yes. But I don't think
changing createObjectURL to sometimes return URLs with permanent
semantics, and sometimes return URLs with temporary semantics is a
good idea.

Also, keep in mind that the use case here is being URLs that are
*predictable* URLs, not just permanent. Even if we generated permanent
blob:<uuid> URLs for Blobs stored in indexedDB, you would need to
store that URL somewhere and then retrieve it when you want to use it.
Having to do that database operation sort of defeats the purpose of
what I was trying to do here.

/ Jonas

Received on Thursday, 18 July 2013 19:04:55 UTC