On 31 Mar 2011, at 1:01 AM, Jonas Sicking wrote:
Anyhow, I do think that the idea of passing in index values at the
same time as a entry is created/modified is an interesting idea. And I
have said so in the past on this list. It's definitely something we
should consider for v2.
Oh, and if
On Thu, Mar 31, 2011 at 12:16 AM, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at 1:01 AM, Jonas Sicking wrote:
Anyhow, I do think that the idea of passing in index values at the
same time as a entry is created/modified is an interesting idea. And I
have said so in the past on this
On 31 Mar 2011, at 9:53 AM, Jonas Sicking wrote:
I previously have asked for a detailed proposal, but so far you have
not supplied one but instead keep referring to other unnamed database
APIs.
I have already provided an adequate interface proposal for putObject and
deleteObject.
I have
On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote:
We have made an effort to understand other contributions to the field.
I'm not convinced that these are essential database concepts and having
personally spent quite some time working with the API in JS and implementing
it, I feel pretty
I was the one that asked for callbacks.
but what do we do if those callbacks don't
return consistent results? Or even do evil things like modify the
stores where data is being inserted?
If the callback maps all values to a sort-order of '1' there could only ever
be one entry in the index...
On 31 March 2011 08:38, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote:
We have made an effort to understand other contributions to the field.
I'm not convinced that these are essential database concepts and having
personally spent quite some time
On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
I totally agree with everything so far...
3. This requires an adjustment to the putObject and deleteObject interfaces
(see previous threads).
I disagree that a simple API change is the answer. The problem is
architectural, not just a
On 31 March 2011 12:41, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
I totally agree with everything so far...
3. This requires an adjustment to the putObject and deleteObject
interfaces (see previous threads).
I disagree that a simple API
On Thu, Mar 31, 2011 at 1:38 AM, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote:
We have made an effort to understand other contributions to the field.
I'm not convinced that these are essential database concepts and having
personally spent quite some
On Thu, Mar 31, 2011 at 5:41 AM, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
I totally agree with everything so far...
3. This requires an adjustment to the putObject and deleteObject
interfaces (see previous threads).
I disagree that a
On Thu, Mar 31, 2011 at 1:32 AM, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at 9:53 AM, Jonas Sicking wrote:
I previously have asked for a detailed proposal, but so far you have
not supplied one but instead keep referring to other unnamed database
APIs.
I have already provided an
On 31 March 2011 18:17, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Mar 31, 2011 at 11:09 AM, Keean Schupke ke...@fry-it.com wrote:
On 31 March 2011 17:41, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 31, 2011 at 1:32 AM, Joran Greef jo...@ronomon.com wrote:
On 31 Mar 2011, at
On Thu, Mar 31, 2011 at 11:24 AM, Keean Schupke ke...@fry-it.com wrote:
On 31 March 2011 18:17, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Mar 31, 2011 at 11:09 AM, Keean Schupke ke...@fry-it.com wrote:
On 31 March 2011 17:41, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 31, 2011
On 31 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:
1. Provide the application with a first-class means to manage indexes at
time of putting/deleting objects.
I'm OK with doing this for v1 if the others are. It doesn't seem like that
big of an addition and it would give a decent amount of
On 31 March 2011 18:36, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Mar 31, 2011 at 11:24 AM, Keean Schupke ke...@fry-it.com wrote:
On 31 March 2011 18:17, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Mar 31, 2011 at 11:09 AM, Keean Schupke ke...@fry-it.comwrote:
On 31 March 2011
On 3/31/2011 11:47 AM, Joran Greef wrote:
Let those who introduced these design flaws be among the first to take
responsibility and fix them.
You aren't being constructive, and that's a surefire way to be ignored.
You have yet to convince the working group that these are design
flaws in the
On 31 Mar 2011, at 10:07 PM, Shawn Wilsher wrote:
On 3/31/2011 11:47 AM, Joran Greef wrote:
Let those who introduced these design flaws be among the first to take
responsibility and fix them.
You aren't being constructive, and that's a surefire way to be ignored. You
have yet to convince
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent: Thursday, March 31, 2011 11:36 AM
I can find a lot of stuff on collation, but not a lot about why it could not
be done in a library. Could you summerise the reasons why this needs to be
core functionality for
Currently there are no APIs in JavaScript to compare strings using
specific collations
We dont actually need this, just a mapping from UTF-16 string to a
sort-score (binary blob).
Its true that downloading the collation tables might take time, so we could
just provide:
var blob =
On Sat, Mar 26, 2011 at 1:14 AM, Nikunj Mehta nik...@o-micron.com wrote:
What is the minimum that can be in IDB? I am guessing the following:
1. Sorted key-opaque value transactional store
2. Lookup of keys by values (or parts thereof)
#1 is essential.
#2 is unavoidable because you would want
What is the minimum that can be in IDB? I am guessing the following:
1. Sorted key-opaque value transactional store
2. Lookup of keys by values (or parts thereof)
#1 is essential.
#2 is unavoidable because you would want to efficiently manipulate values by
values as opposed to values by key.
I
On 26 Mar 2011, at 10:14 AM, Nikunj Mehta wrote:
What is the minimum that can be in IDB? I am guessing the following:
1. Sorted key-opaque value transactional store
2. Lookup of keys by values (or parts thereof)
Yes, this is what we need. In programmer speak: objects (opaque strings),
On 20 Mar 2011, at 4:54 AM, Jonas Sicking wrote:
I don't understand what you are saying about application state though,
so please do start that as a separate thread.
At present, there's no way for an application to tell IDB what indexes to
modify w.r.t. an object at the exact moment when
23 matches
Mail list logo
