On 3/8/2011 6:12 PM, Jeremy Orlow wrote:
On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro
<[email protected] <mailto:[email protected]>> wrote:
From: [email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Keean Schupke
Sent: Tuesday, March 08, 2011 3:03 PM
>> No objections here.
>>
>> Keean.
>>
>> On 8 March 2011 21:14, Jonas Sicking <[email protected]> wrote:
>> On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow
<[email protected] <mailto:[email protected]>> wrote:
>> > On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow
<[email protected] <mailto:[email protected]>> wrote:
>> > After thinking about it a bunch and talking to others, I'm
actually leaning
>> > towards both option A and B. Although this will be a little
harder for
>> > implementors, it seems like there are solid reasons why some
users would
>> > want to use A and solid reasons why others would want to use B.
>> > Any objections to us going that route?
>> Not from me. If I don't hear objections I'll write up a spec
draft and
>> attach it here before committing to the spec.
Option A is pretty well understood, I like that one.
For option B, at some point we had a debate on whether when
indexing an array value we should consider it a single key value
or we should unfold it into multiple index records. The first
option makes it very similar to A in that an array is just a
composite value (it is quite a bit more painful to implement...),
the second option is interesting in that allows for new scenarios
such as objects with an array for tags, where you want to look up
by tag (even after doing options A and B as currently defined, in
order support multiple tags you'd need a second store that keeps
the tags + key for the objects you want to tag). Is there any
interest in that scenario?
Yes. Once we're settled on this, I'm going to send an email on that.
:-) Option b won't get in the way of my proposal.
J
At some point, I really would like to get people from the PostgreSQL
project involved with indexeddb.
They have a wealth of experience to bring to the discussion. For the
moment, like many "server-side" packages, they're at quite a distance
from the w3.
FWIW, pgsql is a perfectly valid 'host' for idb calls.
