On 4/10/09 1:53 PM, Maciej Stachowiak wrote:
I don't think this one point should be decisive by itself. But I don't
think it should be given zero weight either. I do think the existence of
an implementation of the current spec and Web content using it somewhat
raises the burden of proof on
On 11/22/09 3:14 PM, Pablo Castro wrote:
Does this seem reasonable?
This seems reasonable to me. The use case makes sense, and is something
I've seen many times in real life.
Cheers,
Shawn
On 3/5/2010 4:54 AM, Jeremy Orlow wrote:
For what it's worth, regardless of the answers to the above questions, I
think we should switch to a callback based model. It's great to use
events when natural to do so, but this is a very unnatural use. It
provides artificial limitations (only one
Hey all,
I'm starting to work on a prototype of the IndexedDB spec to get a
better understanding of it. While working with the IDBRequest I think I
understand why nobody likes the current event-based model. I'm also
seeing that as it is currently specified, it doesn't meet the
requirements
On 3/22/2010 10:05 AM, Jeremy Orlow wrote:
I also can't seem to figure out what the success event is supposed to be
for just about anything. Am I just missing something, or is this not yet
specified?
When onsuccess fires, you can then start the next request.
Sorry, I guess I'm not being
On 1/31/2010 11:33 PM, Nikunj Mehta wrote:
a. 3.1.3: do we really need in-line + out-of-line keys? Besides
the concept-count increase, we wonder whether out-of-line keys would
cause trouble to generic libraries, as the values for the keys
wouldn't be part of the values iterated when
On 3/22/2010 10:49 AM, Shawn Wilsher wrote:
On 3/13/2010 1:43 AM, Nikunj Mehta wrote:
As specced, it is possible to have multiple concurrent requests at
various API entry points, except for the IndexedDatabaseRequest
interface. In this particular case, you can only have one request to
open
Hey all,
The spec is unspecified as to what we should do when a database is
opened with a different description than it was previously opened. I'd
assume we'd want to update it, but maybe folks have other ideas.
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
On 3/31/2010 6:42 AM, Jeremy Orlow wrote:
I don't see any reason to special case this one method with synchronous
properties. If the name parameter is not valid or any other error, I
think it should be returned via an error callback just like everywhere else.
I agree.
Cheers,
Shawn
On 4/13/2010 8:53 AM, João Eiras wrote:
Not really. The user agent can ask for quota from the user when the
limit is being hit without the webpage even having to worry about it.
Opera 10.50 does that.
I agree with this, and do see the benefit of adding more to the spec.
Cheers,
Shawn
On 4/20/2010 4:11 AM, Mark Seaborn wrote:
1) It doesn't allow a web app to ask for a storage allocation up front,
before it starts to consume the storage.
Why does that matter?
2) In Opera, the quota can only be increased in multiples of about 15, so it
takes three prompts to get up into the
On 4/19/2010 10:08 PM, Jeremy Orlow wrote:
On Tue, Apr 13, 2010 at 3:09 AM, Mark Seabornmseab...@chromium.org wrote:
2) It is too permissive because it enforces no limit on the amount of
space a web app can use: A web app from example.com can create an
unlimited number of puppet
On 3/30/2010 1:37 PM, Shawn Wilsher wrote:
Having open return an IDBRequest and not having the request property on
IndexedDatabaseRequest would solve this problem. I'm going to prototype
an implementation in Mozilla this way to see if any issues come up, but
I don't currently foresee any.
Does
On 4/23/2010 7:39 AM, Nikunj Mehta wrote:
Could we create an additional optional parameter for an open request with the
type of permanence required? Or is it not a good idea?
I haven't talked to anyone at Mozilla that thinks that having permanent
and non-permanent-but-possibly-long-lasting
On 4/28/2010 2:54 PM, Dumitru Daniliuc wrote:
shawn, did you have a chance to give this some thought? how would mozilla
like to handle cases like the ones jeremy and robin mentioned? how would you
like to manage quotas?
We chatted yesterday, but I haven't had a chance to get it down into
On 4/29/2010 1:08 PM, Tab Atkins Jr. wrote:
When you say per site do you mean per subdomain, or per domain? The
former is too permissive, the latter is too restrictive.
I believe he means per origin. At least that's what I took from our
discussion.
Cheers,
Shawn
smime.p7s
Description:
On 5/5/2010 11:44 AM, Jeremy Orlow wrote:
On the other hand, a lot of even the most basic tasks probably should be
done within a transaction. But if the easiest way to do something is to
just run it outside of a transaction, I'm guessing a good portion of users
(including tutorial websites,
On 5/5/2010 1:09 PM, Jeremy Orlow wrote:
I'd also worry that if creating the transaction were completely transparent
to the user that they might not think to close it either. (I'm mainly
thinking about copy-and-paste coders here.)
I should have been more clear. That statement goes along with
Hey all,
Per the current spec [1], noOverwrite defaults to false for put
operations on an object store. Ben Turner and I have been discussing
changing the default of put to not allow overwriting by default. We
feel this is better behavior because simply omitting the flag should not
result
On 5/10/2010 1:33 AM, Jeremy Orlow wrote:
Either sounds fine to me. Please open something in the bug tracker?
Filed bug 9698 [1] on changing noOverwrite to overwrite. I'm going to
wait to file a bug about changing the default until we get more feedback.
Cheers,
Shawn
[1]
On 5/10/2010 10:36 AM, Kris Zyp wrote:
I believe there are three useful modes:
overwrite: false - Must create a new record
overwrite: true - Must overwrite/update an existing record
(something else) - Create a new record or overwrite/update an existing
(depending on the key of course).
FWIW,
Hey all,
A recent concern that we have come across at Mozilla is what happens
when the version changes? Do we silently continue to work and hope for
the best? Do we throw an error every time saying that the version this
database was opened with is no longer the version of the database?
On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
If you search archives you will find a discussion on versioning and that we
gave up on doing version management inside the browser and instead leave it to
applications to do their own versioning and upgrades.
Right, I'm not saying we should manage it,
On 5/18/2010 7:20 AM, Jeremy Orlow wrote:
1. Once a database has been opened (a database connection has been
established) read access to meta-data, such as objectStore and index
names, is synchronous. Changes to such meta data, such as creating
objectStores and indexes, is still asynchronous.
I
On 5/17/2010 6:15 PM, Jonas Sicking wrote:
We've created some examples of what using this proposed API would look like:
http://docs.google.com/document/pub?id=1I__XnwvvSwyjvxi-FAAE0ecnUDhk5DF7L2GI6O31o18
we've also implemented the same examples using the currently drafted API:
On 5/19/2010 1:50 PM, Shawn Wilsher wrote:
Er, and I managed to botch the SQL in the last two examples. Those
should be (if my non-tested SQL-fu is right):
SELECT name, COUNT(kids.id)
FROM kids INNER JOIN candySales
ON kids.id = candySales.kidId
GROUP BY kids.id;
and:
SELECT name, COUNT
On 5/20/2010 2:55 AM, Jeremy Orlow wrote:
Thanks for taking the time to do this!
Can you maybe discuss the pros and cons you found in terms of implementing
something in WebSQLDatabase vs. IndexedDB? I'm mainly interested in seeing
if there's any thing we can improve in IndexedDB that
On 5/20/2010 9:03 AM, Jonas Sicking wrote:
For what it's worth, one of the ideas behind object stores, rather
than rows+column stores, is to reduce the need for joins. I.e. in our
candy store example you could just as well store objects like:
{ id: 1, name: Adam, sales: [{candyId: 1, date:
On 5/20/2010 11:30 AM, Andrei Popescu wrote:
As someone new to this API, I thought the naming used in the current
draft is somewhat confusing. Consider the following interfaces:
IndexedDatabase
IndexedDatabaseRequest,
IDBDatabaseRequest,
IDBDatabase,
IDBRequest
Just by looking at this, it is
On 5/20/2010 12:19 PM, Jonas Sicking wrote:
I additionally like the naming convention. The async interfaces is
probably the interface that people will use first. Additionally that
interface is available both to workers and to the main thread. So it
makes sense to give the async interface the
On 5/20/2010 7:34 AM, Shawn Wilsher wrote:
So far it's really just that joins are painful in IndexedDB. I'm working
on a blog post on this very topic though, and I'll be sure to point
everyone in this thread to it (I figure this is useful stuff to get out
to a wider audience).
And honestly, I
On 4/20/2010 11:46 AM, bugzi...@jessica.w3.org wrote:
The spec is unspecified as to what we should do when a database is opened with
a different description than it was previously opened. I'd assume we'd want to
update the description.
Does anybody else have thoughts on what the right behavior
On 6/8/2010 10:22 AM, bugzi...@jessica.w3.org wrote:
When you open an objectStore with a read only mode, any subsequent write
operation should probably result in an error. I don't see anywhere in the spec
that specifically says this or mentions what error code should be used.
Currently in the
On 6/9/2010 3:48 PM, Kris Zyp wrote:
Another option would be to have cursors essentially implement a JS
array-like API:
db.objectStore(foo).openCursor(range).forEach(function(object){
// do something with each object
}).onsuccess = function(){
// all done
});
(Or perhaps the cursor with
On 6/9/2010 3:36 PM, Tab Atkins Jr. wrote:
At the very least, explicitly loading things into an honest-to-god
array can make it more obvious that you're eating memory in the form
of a big array, as opposed to just a magically transform my blob of
data into something more convenient.
I'm sorry,
On 6/16/2010 9:43 AM, Nikunj Mehta wrote:
There are three theoretical modes as you say. However, the second mode does not
exist in practice. If you must overwrite, then you know that the record exists
and hence don't need to specify that option.
To be clear, you are saying that there are only
On 6/24/2010 7:01 AM, Jeremy Orlow wrote:
So what your proposing is that the keyPath would essentially be a string of
the body of a function which runs for every index (on that objectStore) for
every value inserted into that object store? This seems like half way
between the eval-like idea I
Hey all,
I think that IDBEvent needs to inherit from Event [1] in order for us to
properly inherit from EventTarget in IDBRequest. Specifically,
EventTarget takes an EventListener [2] which has a method, handleEvent,
that takes an Event object. I'm not sure this makes sense for us
though,
On 6/28/2010 4:59 PM, Jeremy Orlow wrote:
Gotcha. Yeah, this technique can be used to replace any use case for
explicitly managed indexes. And, for that reason, I think we should just
get rid of them now.
Agreed.
As for whether we should have a feature to compute index keys via
a function:
On 6/30/2010 8:25 AM, Andrei Popescu wrote:
Agreed. In WebKit, Jeremy already made it inherit from Event.
I filed bug 10056 [1] on this.
Cheers,
Shawn
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10056
smime.p7s
Description: S/MIME Cryptographic Signature
On 7/5/2010 3:19 AM, Nathan Kitchen wrote:
There are a couple of ways to do this:
I think you missed one. IDBDatabase has a property objectStores [1]
that is an array of object stores. Additionally, IDBObjectStore has a
property called indexNames [2] that is an array of indexes for the
On 7/6/2010 6:31 PM, Nikunj Mehta wrote:
To begin with, 10052 shuts down the users of the database completely when
only one is changing its structure, i.e., adding or removing an object
store. How can we make it less draconian? Secondly, I don't see how that
approach can produce atomic changes
On 7/7/2010 12:27 AM, Jonas Sicking wrote:
This interface allows asynchronously requesting more objectStores to
be locked. The author must take care whenever calling openObjectStores
that the request might fail due to deadlocks.
But as previously stated, I think this adds too much complexity
On 7/9/2010 11:05 AM, Nikunj Mehta wrote:
We would not make dynamic transactions be the default since they would produce
more concurrency than static scoped transactions, correct?
I'm still of the opinion that dynamic transactions are a bad idea
because it's too easy to hold a transaction
On 7/9/2010 12:50 PM, Nikunj Mehta wrote:
The point is that we are talking of leaving out dynamic scope in v1, while, in the same
vein, talking of making READ_ONLY the default _because_ it produces good
performance. That is, IMHO, contradictory.
Dynamic scope == dynamic transactions, correct?
Hey all,
Some of the feedback I've been seeing on the web is that there is no way
to remove a database. Examples seem to be web page wants to allow the
user to remove the data they stored. A site can almost accomplish this
now by removing all object stores, but we still end up storing some
On 8/4/2010 10:24 AM, Jeremy Orlow wrote:
Jonas/Shawn: Since it seems you've been getting some feedback on your
implementation, do you have any data to suggest that implicit transactions
are being used and considered helpful in the wild?
I have not yet seen any specific feedback about it as
On 8/4/2010 8:42 AM, Jeremy Orlow wrote:
In the IndexedDB spec, there are two ways to create a transaction. One is
explicit (by calling IDBDatabase.transaction()) and one is implicit (for
example, by calling IDBDatabase.objectStore.get(someKey)). I have
questions about the latter, but before
Hey guys,
Someone just posted a link to this on one of our blog posts about
IndexedDB and I figured I'd share it with the list since it's pretty
darn neat:
http://tinyurl.com/ff-idxdb
It appears to be sample code + documentation mixed together. It does
seem to be a bit specific to our
On 8/4/2010 10:53 AM, Jeremy Orlow wrote:
Whoatransaction() is synchronous?!? Ok, so I guess the entire premise
of my question was super confused. :-)
It is certainly spec'd that way [1]. The locks do not get acquired
until the first actual bit of work is done though.
Cheers,
On 8/9/2010 1:13 PM, Andrei Popescu wrote:
While implementing IDBFactory::open(), we thought that the
description argument is optional but we were surprised to find out
it's actually mandatory. Is there any reason not to make this argument
optional? And, assuming it is optional, should the
On 8/31/2010 12:03 PM, Jonas Sicking wrote:
So IMHO we should heavily optimize for javascript, while ensuring that
other languages are possible.
Yes, please.
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
On 9/17/2010 3:14 PM, Jonas Sicking wrote:
How do you then guarantee that a transaction that spans multiple
objectStores either fully succeeds or is fully rolled back? Especially
in the event of a crash during commit.
If you don't use write ahead logging, and connect to each database with
On 9/28/2010 7:42 AM, Jeremy Orlow wrote:
What do we want to do if the user calls window.indexedDB.open(myDB, some
description) twice and stores the result as db1 and db2, calls
db1.setVersion(), and then in the success handler does
db2.createObjectStore? In other words, is the setVersion
On 9/29/2010 6:12 AM, Jeremy Orlow wrote:
Off the top of my head, I can think of two behaviors we might want to spec:
1) Have the subsequent setVersion simply throw an error. 2) Have the
subsequent setVersion adopt the existing setVersion transaction and change
the version. (i.e. whatever
On 9/30/2010 2:16 AM, Jeremy Orlow wrote:
Hm. Actually, I think I like Jonas' proposal better than 1 or 2 (and Shawn,
I see your point about why 2 is better than 1). I also think that Shawn's
example of doing multiple schema upgrades should still work 3 since we fire
onsuccesses in the order
On 11/1/2010 5:29 AM, Jeremy Orlow wrote:
If not, I think we should avoid adding surface area for something we don't
really understand very well.
I agree with this. Less is better at this point I think (when
appropriate, of course).
Cheers,
Shawn
smime.p7s
Description: S/MIME
On 11/9/2010 12:35 AM, Jonas Sicking wrote:
One thing we could do is to move
.source
.transaction
.result
.error
to IDBRequest. Then make success and error events be simple events
which only implement the Event interface. I.e. we could get rid of the
IDBEvent, IDBSuccessEvent,
On 11/11/2010 11:44 AM, Jeremy Orlow wrote:
The email I responded to: It would make sense if you make setting a key to
undefined semantically equivalent to deleting the value (and no error if it
does not exist), and return undefined on a get when no such key exists. That
way 'undefined' cannot
On 12/10/2010 5:03 AM, Jeremy Orlow wrote:
Speaking of which, we use UNKNOWN_ERR for a bunch of other
internal consistency issues. Is this OK by everyone, should we use another,
or should we create a new one? (Ideally these issues will be few and far
between as we make things more robust.)
On 12/10/2010 7:27 AM, Jeremy Orlow wrote:
We did all of these two weeks ago in Chromium and have gotten some feedback.
The main downside is that typos are silently ignored by JavaScript. We
considered throwing if someone passed in an option we didn't recognize, but
this would make it
On 12/14/2010 4:16 PM, Jeremy Orlow wrote:
Shawn said NOT_FOUND_ERR. NOT_ALLOWED_ERR seems slightly better to me.
Shawn, what do you think?
I don't have a strong opinion either way.
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
On 12/29/2010 2:44 PM, Axel Rauschmayer wrote:
The pattern of assigning the success continuation after invoking the operation
seems to be to closely tied to JavaScript’s current run-to-completion event
handling. But what about future JavaScript environments, e.g. a multi-threaded
Node.js with
On 1/28/2011 1:15 AM, Axel Rauschmayer wrote:
All API invocations that I have seen relied on run-to-completion semantics and
add a listener after the initial invocation. These now have to check the flag?
No, all that works just like it did before. The flag just allows for
some additional
On 1/28/2011 1:07 AM, Axel Rauschmayer wrote:
Agreed. My only aside would be that for API design, it’s usually not a good
idea to listen to web developers, but to someone who has experience with
designing DB APIs (= not me, but possibly anyone of you or anyone at Mozilla,
MS, Google).
It
On 2/3/2011 3:59 PM, João Eiras wrote:
Because the user agent needs to differentiate which api will use each
quota.
But why does a user agent need to do that? It seems like that is adding
unnecessary complication to the API.
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic
On 2/3/2011 4:35 PM, João Eiras wrote:
Or adding unnecessary complication to the implementation.
I'm not looking to make my job easier (as an implementer); I'm looking
to make it easy to use. At least with IndexedDB, we generally choose
the option that is easier for the consumer as long as it
On 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote:
As discussed in the mailing list thread from bug 11257, we should add some way
for index.openCursor cursors to access the primary key for the objectStore.
.indexValue, .objectStoreKey, or .primaryKey might be good names to use for it.
On 2/6/2011 12:42 PM, Jeremy Orlow wrote:
My current thinking is that we should have some relatively large
limitmaybe on the order of 64k? It seems like it'd be very difficult to
hit such a limit with any sort of legitimate use case, and the chances of
some subtle data-dependent error would
On 2/7/2011 12:32 AM, Glenn Maynard wrote:
Is that a safe assumption to design around? The API might later be bound to
other languages fortunate enough not to be stuck in UTF-16.
As I recall, we've already made design decisions based on the fact that
the primary consumer of this API is going
On 2/8/2011 11:51 AM, ben turner wrote:
I'm actually fine with keeping the setVersion from proceeding until
the old database is collected. First, this is probably a bug in the
web page, and the page should be fixed. Second, the new database that
is waiting for setVersion to proceed will get an
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 4/1/2011 5:40 AM, Nathan Kitchen wrote:
Are there any browser vendor representatives on the mailing list who would
care to comment on the criteria for implementing something akin to Keean's
RelationalDBhttps://github.com/keean/RelationalDB idea? What would need
to be in place to start work
On 4/1/2011 9:39 AM, Aryeh Gregor wrote:
IE6 is closed-source software written for a single platform. SQLite
is in the public domain, works for all major operating systems and
lots of minor ones, and is already used (I think?) by every major
browser except IE. That makes all the difference.
On 4/4/2011 8:07 AM, Joran Greef wrote:
SQLite has a fantastic track record of maintaining backwards compatibility.
Sort of. They didn't between SQLite 2 and SQLite 3. There also have
been some (albeit minor) backwards compatibility issues with SQLite 3.x
releases. The most serious of which
On 4/4/2011 10:28 AM, Joran Greef wrote:
Do you think it would be wise then to advocate doing away with SQLite before
IndexedDB has had a chance to prove itself? Surely two competing APIs would be
the fastest way to bring IndexedDB up to speed?
Who is advocating doing away with it? Note that
On 4/4/2011 10:18 AM, Joran Greef wrote:
How would you create an index on an existing object store in IndexedDB
containing more than 50,000 objects on an iPad, without incurring any object
deserialization/serialization overhead, without being an order of magnitude
slower than SQLite, and
On 4/6/2011 9:44 AM, Joran Greef wrote:
We only need one fixed version of SQLite to be shipped across Chrome, Safari,
Opera, Firefox and IE. That in itself would represent a tremendous goal for
IndexedDB to target and to try and achieve. When it actually does, and
surpasses the fixed version
On 4/6/2011 10:06 AM, Joran Greef wrote:
I bring up the iPad example because I had experience with a LocalStorage
implementation (I think it was Safari) loading the contents of LocalStorage
into memory synchronously on first access, blocking the UI thread. I am
probably wrong on this one but
On 4/20/2011 1:33 PM, Israel Hilerio wrote:
The open method description in the IDBFactory talks about setting the source of the IDBRequest to no
source. What does no source means (undefined, null, other)?
In addition, what should be the value of the transaction property in the IDBRequest
On 5/6/2011 7:07 AM, timeless wrote:
I think that a stored procedure could be considered as a compiled
version of a serialized function. i.e. something which loses its scope
chain, and which loses access to its parent object. If it loses access
to its scope chain which includes the interesting
On 5/31/2011 10:56 AM, Israel Hilerio wrote:
Should I interpret the silence to mean we agree?
I believe that's a safe thing to do :)
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
On 6/6/2011 12:03 PM, Israel Hilerio wrote:
Have you considered using the WebIDL dictionary definition as a mechanism to
define the optional parameters in the IDBDatabase.createObjectStore method?
I don't believe this was available when we added this. Changing this
seems sensible to me.
On 8/15/2011 3:31 PM, Israel Hilerio wrote:
When the db is doing a commit after processing all records on the
transaction, if for some reason it fails, should we produce an error
event first and let the bubbling produce a transaction abort event or
should we only produce a transaction abort
84 matches
Mail list logo
