Hi Christoph,
On 17 Jun 2010, at 14:26, Christoph Storm wrote:
Hi,
I am currently very busy reading your papers about W3C Widgets because I am
writing my master thesis about Widgets. The title is Device interoperable
data visualization using standard W3C Widgets - the important word is
Eric,
Based upon your responses there are a couple of additional things we
need to check on, but I'll look deeper into the current specs for the
things that should already be supported.
The additional things are:
- how to safely grant access outside the sandbox, which depends upon
ability to
Hi All,
One thing that (if I'm reading the spec correctly) is currently
impossible is to create multi-valued keys. Consider for example an
object store containing objects like:
{ firstName: Sven, lastName: Svensson, age: 57 }
{ firstName: Benny, lastName: Andersson, age: 63 }
{ firstName: Benny,
Hi All,
One thing that we've talked a bit about at mozilla is about in which
order asynchronous events should fire. I.e. for code like:
results = [];
trans = db.transaction([mystore]);
trans.objectStore(mystore).get(1).onsuccess = function(e) {
results.push(e.result);
}
The complex keys are how we do this in CouchDB as well. But, again,
the sorting algorithm needs to be well defined in order for it work.
http://wiki.apache.org/couchdb/View_collation#Collation_Specification
Most pertinent to your example is how arrays of varying length might
be ordered, for
On Fri, Jun 18, 2010 at 5:03 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
The complex keys are how we do this in CouchDB as well. But, again,
the sorting algorithm needs to be well defined in order for it work.
http://wiki.apache.org/couchdb/View_collation#Collation_Specification
Most
+1 on composite keys in general. The alternative to the proposal below would be
to have the actual key path specification include multiple members (e.g.
db.createObjectStore(foo, [a, b])). I like the proposal below as well, I
just wonder if having the key path specification (that's external to
Reading back over my email is sounds opposing and that wasn't my
intention, it was a long way of saying +1 and giving an explanation
for why we went with the same approach in CouchDB.
-Mikeal
On Fri, Jun 18, 2010 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 18, 2010 at 5:03 PM,
I didn't take it as opposing at all. I figured you'd like it as I
based it on your description of how you do it in CouchDB ;-)
I just wanted to make sure that we nail down all the details,
including the sorting order, so if you see anything wrong definitely
point it out!
/ Jonas
On Fri, Jun 18,
The biggest hole I see, even larger than sorting other types, is what
we use for string comparisons. In CouchDB we use the unicode collation
algorithm which is heavy but very well defined and works across
various localizations.
-Mikeal
On Fri, Jun 18, 2010 at 5:26 PM, Jonas Sicking
On Fri, Jun 18, 2010 at 5:18 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
+1 on composite keys in general. The alternative to the proposal below would
be to have the actual key path specification include multiple members (e.g.
db.createObjectStore(foo, [a, b])). I like the proposal
Yes, I think this is orthogonal to the issue of composite keys so I'd
rather deal with that in a separate thread.
/ Jonas
On Fri, Jun 18, 2010 at 5:30 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
The biggest hole I see, even larger than sorting other types, is what
we use for string
I would like to see null and bool types in arrays as well.
null is useful if it is assured to sort before any other type, bool
types are useful if you want to use integers in the same sort as you
want bools and therefor could not just use 0 and 1 instead.
If you add all these new types (null,
On Friday, June 18, 2010, Mikeal Rogers mikeal.rog...@gmail.com wrote:
I would like to see null and bool types in arrays as well.
null is useful if it is assured to sort before any other type, bool
types are useful if you want to use integers in the same sort as you
want bools and therefor
I think determinism is most important for the reasons you cited. I think
advanced, performance concerned apps could deal with either semantics you
mentioned, so the key would be to pick whatever is best for the normal case.
I'm leaning towards thinking firing in order is the best way to go
Another possible meaning for arrays is allowing someone to insert multiple
values into an index that point to one object store. For example:
{ names: [Sarah, Jessica, Parker], ...}
{ names: [Bono], ...}
{ names: [Jonas, Sicking], ...}
Then I could look up Sicking inside an index with a keyPath
On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow jor...@chromium.org wrote:
I think determinism is most important for the reasons you cited. I think
advanced, performance concerned apps could deal with either semantics you
mentioned, so the key would be to pick whatever is best for the normal
On Thu, Jun 17, 2010 at 3:25 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
We've debated a bit use cases like storing objects like:
{ name: Elvis, born: January 8, 1935, died: August 16, 1977 }
{ name: Gustav III, born: 24 January 1746, died: 29 March 1792 }
And create an index based
On Fri, Jun 18, 2010 at 7:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow jor...@chromium.org wrote:
I think determinism is most important for the reasons you cited. I think
advanced, performance concerned apps could deal with either semantics you
19 matches
Mail list logo
