For a deeper Indexed Database API (nested ObjectStores)
Hello,
I recently experimented with this API trying to simulate a file system, but
I am sad to see a lack of depth.
To preserve the environment applications using my tool, I want to create
only one database for my filesystem.
So I create my database, I add a table representing a folder and I save my
files, until this point, it's ok.
The design problem is when I have to simulate a subfolder ...
I then create another database, but it does not seem very clean because the
user of the application should be able to create your own folders,
subfolders and files, and the application using my tool should also be able
to create their own databases data ... there is therefore a risk of
conflict.
Using only one database should therefore go through the creation of a table
folder or subfolder.
Ok, it's doable ... However, it would ruin the performance, because when
you open a database, the API returns an object containing the
objectStoreNames property that contains the list of all tables in the
database.
Assuming that my file system contains thousands of folders and sub-folders,
once the database is opened, the API will have to recover the full list,
while operations to this file system in perhaps one or two concern.
I can store objects in the records of my tables but this would retrieve an
object that can be huge, again, while operations to this file system can be
a concern or two.
None of these solutions seem to me, at once, clean and optimal in terms of
resources.
My idea is that it may be more optimal to save a table in the fields of a
record in another table and could overcome the lack of relationships.
Since a picture is better than a long explanation, here is an example
schema ObjectStores nested:
indexedDB = {
database: {
directory_0: {
subdirectory: {
// ...
}
},
directory_1: {
// ...
},
file_0.txt,
file_1.txt
}
}
For additional and / or feedback information, do not hesitate to contact me.
;)
Michaël
RE: For a deeper Indexed Database API (nested ObjectStores)
It’s an interesting problem that you’re trying to solve and I’ve had a crack at
my own implementation which you can find here -
https://github.com/aaronpowell/indexeddb-filesystem
A few implementation points:
- I don’t think you want to split across multiple objectStores in your
database, that’ll make it very slow to query as can’t build up indexes
- My implementation is a flat structure which you have parent IDs
tracked against each object so you’re building up a tree of sorts in your
database
- While I haven’t implemented it (at present) to get back the contents
of a folder you would do something like:
var transaction = db.transaction(storeName);
var store = transaction.objectStore(storeName);
var index = store.index(‘parent’);
var range = IDBKeyRange.only(parent id);
index.openCursor(range).onsuccess = function (e) {
//track items that the cursor gets
};
- You could also look at doing stuff like using array indexes to store
the full parent path which you can then query across
Anyway I might keep playing with my implementation to see how it turns out.
Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team
Memberhttp://funnelweblog.com/
http://apowell.mehttp://apowell.me/ | http://twitter.com/slace | Skype:
aaron.l.powell | Githubhttp://github.com/aaronpowell/ |
BitBuckethttp://hg.apwll.me/
From: Michaël Rouges [mailto:michael.rou...@gmail.com]
Sent: Monday, 22 April 2013 5:31 PM
To: public-webapps@w3.org
Subject: For a deeper Indexed Database API (nested ObjectStores)
Hello,
I recently experimented with this API trying to simulate a file system, but I
am sad to see a lack of depth.
To preserve the environment applications using my tool, I want to create only
one database for my filesystem.
So I create my database, I add a table representing a folder and I save my
files, until this point, it's ok.
The design problem is when I have to simulate a subfolder ...
I then create another database, but it does not seem very clean because the
user of the application should be able to create your own folders, subfolders
and files, and the application using my tool should also be able to create
their own databases data ... there is therefore a risk of conflict.
Using only one database should therefore go through the creation of a table
folder or subfolder.
Ok, it's doable ... However, it would ruin the performance, because when you
open a database, the API returns an object containing the objectStoreNames
property that contains the list of all tables in the database.
Assuming that my file system contains thousands of folders and sub-folders,
once the database is opened, the API will have to recover the full list, while
operations to this file system in perhaps one or two concern.
I can store objects in the records of my tables but this would retrieve an
object that can be huge, again, while operations to this file system can be a
concern or two.
None of these solutions seem to me, at once, clean and optimal in terms of
resources.
My idea is that it may be more optimal to save a table in the fields of a
record in another table and could overcome the lack of relationships.
Since a picture is better than a long explanation, here is an example schema
ObjectStores nested:
indexedDB = {
database: {
directory_0: {
subdirectory: {
// ...
}
},
directory_1: {
// ...
},
file_0.txt,
file_1.txt
}
}
For additional and / or feedback information, do not hesitate to contact me. ;)
Michaël
Re: For a deeper Indexed Database API (nested ObjectStores)
Hi Michaël,
I also implemented a filesystem solution on top of IDB:
https://github.com/ebidel/idb.filesystem.js/blob/master/src/idb.filesystem.js
It's a polyfill for the W3C Filesystem API [1]. The abstraction is nice
because it
takes away the hairy details (as you've encountered) of trying to use IDB
as a filesystem.
My approach was similar to Aaron's. There's only one database and one
object store.
Subfolders are implemented by saving files keyed off their fullPath and
cleverly using IDBKeyRanges.bound. Something like:
var DIR_SEPARATOR = '/';
var OPEN_BOUND = String.fromCharCode(DIR_SEPARATOR.charCodeAt(0) + 1);
var fullPath = '/path/to/folder/';
IDBKeyRange.bound(fullPath, fullPath + OPEN_BOUND , false, true);
restricts the results in such a way that the keys that are returned only
fall under the
virtual folder /path/to/folder/.
Hope that helps. There's a demo here Demo:
http://html5-demos.com/static/filesystem/idb.filesystem.js/demos/basic/index.html
if
you're interested.
[1]: http://www.w3.org/TR/file-system-api/
On Mon, Apr 22, 2013 at 2:13 AM, Aaron Powell m...@aaron-powell.com wrote:
It’s an interesting problem that you’re trying to solve and I’ve had a
crack at my own implementation which you can find here -
https://github.com/aaronpowell/indexeddb-filesystem
** **
A few implementation points:
**- **I don’t think you want to split across multiple
objectStores in your database, that’ll make it very slow to query as can’t
build up indexes
**- **My implementation is a flat structure which you have
parent IDs tracked against each object so you’re building up a tree of
sorts in your database
**- **While I haven’t implemented it (at present) to get back
the contents of a folder you would do something like:
** **
var transaction = db.transaction(storeName);
var store = transaction.objectStore(storeName);
var index = store.index(‘parent’);
var range = IDBKeyRange.only(parent id);
** **
index.openCursor(range).onsuccess = function (e) {
//track items that the cursor gets
};
** **
**- **You could also look at doing stuff like using array
indexes to store the full parent path which you can then query across
** **
Anyway I might keep playing with my implementation to see how it turns out.
** **
** **
Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team
Memberhttp://funnelweblog.com/
http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
Github http://github.com/aaronpowell/ | BitBucket http://hg.apwll.me/
** **
*From:* Michaël Rouges [mailto:michael.rou...@gmail.com]
*Sent:* Monday, 22 April 2013 5:31 PM
*To:* public-webapps@w3.org
*Subject:* For a deeper Indexed Database API (nested ObjectStores)
** **
Hello,
I recently experimented with this API trying to simulate a file system,
but I am sad to see a lack of depth.
To preserve the environment applications using my tool, I want to create
only one database for my filesystem.
So I create my database, I add a table representing a folder and I save my
files, until this point, it's ok.
The design problem is when I have to simulate a subfolder ...
I then create another database, but it does not seem very clean because
the user of the application should be able to create your own folders,
subfolders and files, and the application using my tool should also be able
to create their own databases data ... there is therefore a risk of
conflict.
Using only one database should therefore go through the creation of a
table folder or subfolder.
Ok, it's doable ... However, it would ruin the performance, because when
you open a database, the API returns an object containing the
objectStoreNames property that contains the list of all tables in the
database.
Assuming that my file system contains thousands of folders and
sub-folders, once the database is opened, the API will have to recover the
full list, while operations to this file system in perhaps one or two
concern.
I can store objects in the records of my tables but this would retrieve an
object that can be huge, again, while operations to this file system can be
a concern or two.
None of these solutions seem to me, at once, clean and optimal in terms of
resources.
My idea is that it may be more optimal to save a table in the fields of a
record in another table and could overcome the lack of relationships.
Since a picture is better than a long explanation, here is an example
schema ObjectStores nested:
indexedDB = {
database: {
directory_0: {
subdirectory: {
// ...
}
},
directory_1: {
// ...
},
file_0.txt,
file_1.txt
}
}
For additional and / or feedback information, do not hesitate to contact
me. ;)
Michaël
Re: For a deeper Indexed Database API (nested ObjectStores)
Thank you to you for your answers. I watched your codes and, in my opinion, this kind of operation is much heavier than it should. Plus there are any files on the system, the operation will require more treatments. My idea would have the advantage of dividing the system into smaller sections (one for each folder / subfolder). I will continue to work my code to illustrate my vision of it and I will share it soon. ;) Michaël
Re: roadmap for inclusion of people with cognitive disabilities
Hi Lisa, On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman lisa.see...@zoho.com wrote: Over the weekend I put up a (very) draft outline for a roadmap for inclusion of people with cognitive disabilities. See http://athenatechnologies.org/RoadmapCog01.html. The most relivent part is probebly the specification suggestion at http://athenatechnologies.org/RoadmapCog01.html#specification. Do you think we should set some time at the FTF to see how WebAPPs can fit in? Hi Lisa, After talking to my co-chair, we believe are not ready to schedule WebApps time for this. The draft is at too early and too conceptual a stage so far. Web Apps generally works on a more or less concrete proposal for a given API or set of APIs (and assocaited markup as relevant). We don't think the group has the necessary expertise and understanding to be an effective place to develop the work from its current stage. If you will be at the meetings I encourage you to talk to *people* from Web Apps, and explain the direction you are working in, to see if they can offer insight or if you can offerit to them. But I think that at this stage you should be developing this further in WAI before coming back to Web Apps with a potential proposal for work. (There may be resistance there to some of the things you are aiming to do, but it is less than in other places, and there is more expertise there than in other parts of W3C). Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
InedxedDB events : misconception?
Hello everyone,
I'm surprised by how events are added to IndexedDB objects.
For example, base, opening a database:
var request;
request = indexedDB.open('database');
request.onsuccess = function () {};
request.onupgradeneeded = function () {};
request.onerror = function () {};
As you can see, the events are added after the query execution.
It does not seem natural and can cause stability problems.
Indeed, if the application had to be completed by the addition of events,
they will never be triggered.
Here is an example generates an error:
var request;
request = indexedDB.open('database');
setTimeout(function () {
request.onsuccess = function () {};
request.onupgradeneeded = function () {};
request.onerror = function () {};
}, 1500);
In my view, any item requiring events should be set first, then we add the
events and finally, we execute it.
The code should look like this:
var request;
request = indexedDB.open('database');
request.onsuccess = function () {};
request.onupgradeneeded = function () {};
request.onerror = function () {};
request.execute();
For additional information and / or feedback, do not hesitate to contact
me. ;)
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 9:43 AM, Michaël Rouges
michael.rou...@gmail.com wrote:
Hello everyone,
I'm surprised by how events are added to IndexedDB objects.
For example, base, opening a database:
var request;
request = indexedDB.open('database');
request.onsuccess = function () {};
request.onupgradeneeded = function () {};
request.onerror = function () {};
As you can see, the events are added after the query execution.
It does not seem natural and can cause stability problems.
Indeed, if the application had to be completed by the addition of events,
they will never be triggered.
Events don't fire until the next tick. As long as you don't spin the
event loop, there's no race conditions and everything's fine.
Here is an example generates an error:
var request;
request = indexedDB.open('database');
setTimeout(function () {
request.onsuccess = function () {};
request.onupgradeneeded = function () {};
request.onerror = function () {};
}, 1500);
This... is precisely the sort of thing that you shouldn't do. Just
don't do this, and you're golden.
In my view, any item requiring events should be set first, then we add the
events and finally, we execute it.
The code should look like this:
var request;
request = indexedDB.open('database');
request.onsuccess = function () {};
request.onupgradeneeded = function () {};
request.onerror = function () {};
request.execute();
The request.execute() is more or less implied by hitting the bottom
of your function, when it returns control back to the browsers.
~TJ
Re: InedxedDB events : misconception?
Hum ... thank you for this answer, but ... Are you sure there is no possibility that the application is completed before adding events? I find it hard to perceive how it couldn't happen.
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges michael.rou...@gmail.com wrote: Hum ... thank you for this answer, but ... Are you sure there is no possibility that the application is completed before adding events? I find it hard to perceive how it couldn't happen. I don't quite understand what you're asking. Are you asking if I'm sure that events will never be sent before the end of your function? Yes, I'm sure of this - it's part of Javascript's core semantics. As long as you register your callbacks before you yield control back to the browser, there is absolutely no chance of you missing any events. ~TJ
Re: InedxedDB events : misconception?
On 4/22/13 12:47 PM, Tab Atkins Jr. wrote:
As long as you don't spin the event loop
That's tricky. Here's some simple code at global scope:
request = indexedDB.open('database');
request.onsuccess = function () {};
Can that code spin the event loop between the open() call and the
onsuccess setter being invoked?
Sure: all it takes is someone defining a setter for request on the
window that just saves the given value and a getter for request that
calls showModalDialog to ask the user whether to allow the get and then
returns the saved value.
Now why someone would do that, I have no idea, but that's true for a lot
of things people do in practice in websites. ;) My point is that
whether the event loop spins is a very non-local property of the code.
It's annoying to have to depend on such things.
Is there a reason to not pass the success/error/upgradeneeded callbacks
in a dictionary to open() in this case, so that the request object is
born with the right bits and the actual reques it not kicked off until
_after_ the side-effects of getting them off the dictionary have fully
run to completion?
This... is precisely the sort of thing that you shouldn't do. Just
don't do this, and you're golden.
I don't believe you are; see above.
The request.execute() is more or less implied by hitting the bottom
of your function, when it returns control back to the browsers.
We wish; see above.
-Boris
Re: InedxedDB events : misconception?
Sorry, I usually speak french and my english is quite experimental. The example I gave, with SetTimeout() is useless, if not illustrate that the interpreter does not expect that the events are attached to execute the query. My surprise comes from the comparison with the XMLHttpRequest object, which is usually added events before executing the query. This behavior (XMLHttpRequest) seems more natural to me. It creates the object and its properties and only then starts the execution may require these properties. As it happens, with IndexedDB objects, we can only hope that the events are attached before, by the interpreter.
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 10:17 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/22/13 12:47 PM, Tab Atkins Jr. wrote:
As long as you don't spin the event loop
That's tricky. Here's some simple code at global scope:
request = indexedDB.open('database');
request.onsuccess = function () {};
Can that code spin the event loop between the open() call and the onsuccess
setter being invoked?
Sure: all it takes is someone defining a setter for request on the window
that just saves the given value and a getter for request that calls
showModalDialog to ask the user whether to allow the get and then returns
the saved value.
Now why someone would do that, I have no idea, but that's true for a lot of
things people do in practice in websites. ;) My point is that whether the
event loop spins is a very non-local property of the code. It's annoying to
have to depend on such things.
Is there a reason to not pass the success/error/upgradeneeded callbacks in a
dictionary to open() in this case, so that the request object is born with
the right bits and the actual reques it not kicked off until _after_ the
side-effects of getting them off the dictionary have fully run to
completion?
Dunno, ask sicking. But events do have some benefits over passed callbacks.
(The right answer is to figure out some way to accommodate IDB's
locking semantics in a future. sicking and annevk have some
discussion on this. Then there's no possibility of event races,
because your callback will still be fired even if you lose the race.)
This... is precisely the sort of thing that you shouldn't do. Just
don't do this, and you're golden.
I don't believe you are; see above.
The request.execute() is more or less implied by hitting the bottom
of your function, when it returns control back to the browsers.
We wish; see above.
Synchronously spinning the event loop is the devil. :/
~TJ
Re: InedxedDB events : misconception?
On 4/22/13 1:31 PM, Tab Atkins Jr. wrote: Is there a reason to not pass the success/error/upgradeneeded callbacks in a dictionary to open() in this case, so that the request object is born with the right bits and the actual reques it not kicked off until _after_ the side-effects of getting them off the dictionary have fully run to completion? Dunno, ask sicking. But events do have some benefits over passed callbacks. I don't understand the distinction. My straw-man proposal here is just that there is a dictionary with the three callbacks and then the return value has its onsuccess/onerror/onupgradeneeded set to those three callbacks before the actual request is kicked off and the request object is returned. (The right answer is to figure out some way to accommodate IDB's locking semantics in a future. sicking and annevk have some discussion on this. Then there's no possibility of event races, because your callback will still be fired even if you lose the race.) That would be good, yes. Synchronously spinning the event loop is the devil. :/ Well, yes. ;) -Boris
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 10:36 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/22/13 1:31 PM, Tab Atkins Jr. wrote: Is there a reason to not pass the success/error/upgradeneeded callbacks in a dictionary to open() in this case, so that the request object is born with the right bits and the actual reques it not kicked off until _after_ the side-effects of getting them off the dictionary have fully run to completion? Dunno, ask sicking. But events do have some benefits over passed callbacks. I don't understand the distinction. Callback arguments can only be registered once. Events can be listened to multiple times. Whether or not that distinction is useful here can be debated, but it's a salient difference. ~TJ
Re: roadmap for inclusion of people with cognitive disabilities
Lisa, If you want to setup an adhoc discussion on your proposal, please let me know and I will join. Thanks, Bryan Sullivan On Apr 22, 2013 9:42 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi Lisa, On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman lisa.see...@zoho.com wrote: Over the weekend I put up a (very) draft outline for a roadmap for inclusion of people with cognitive disabilities. See http://athenatechnologies.org/**RoadmapCog01.htmlhttp://athenatechnologies.org/RoadmapCog01.html. The most relivent part is probebly the specification suggestion at http://athenatechnologies.org/**RoadmapCog01.html#**specificationhttp://athenatechnologies.org/RoadmapCog01.html#specification . Do you think we should set some time at the FTF to see how WebAPPs can fit in? Hi Lisa, After talking to my co-chair, we believe are not ready to schedule WebApps time for this. The draft is at too early and too conceptual a stage so far. Web Apps generally works on a more or less concrete proposal for a given API or set of APIs (and assocaited markup as relevant). We don't think the group has the necessary expertise and understanding to be an effective place to develop the work from its current stage. If you will be at the meetings I encourage you to talk to *people* from Web Apps, and explain the direction you are working in, to see if they can offer insight or if you can offerit to them. But I think that at this stage you should be developing this further in WAI before coming back to Web Apps with a potential proposal for work. (There may be resistance there to some of the things you are aiming to do, but it is less than in other places, and there is more expertise there than in other parts of W3C). Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: InedxedDB events : misconception?
On 4/22/13 1:41 PM, Tab Atkins Jr. wrote: On Mon, Apr 22, 2013 at 10:36 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/22/13 1:31 PM, Tab Atkins Jr. wrote: Is there a reason to not pass the success/error/upgradeneeded callbacks in a dictionary to open() in this case, so that the request object is born with the right bits and the actual reques it not kicked off until _after_ the side-effects of getting them off the dictionary have fully run to completion? Dunno, ask sicking. But events do have some benefits over passed callbacks. I don't understand the distinction. Callback arguments can only be registered once. Events can be listened to multiple times. What I meant is that I don't understand the distinction between the two in this particular case, when I am proposing that the callback arguments be registered as event listeners by the call. I understand the general difference between the two, thanks. ;) This does mean that if you have more than one success listener you lose, of course -Boris
Re: roadmap for inclusion of people with cognitive disabilities
sure, that would be great. Let me know when is good. All the best Lisa On Mon, 22 Apr 2013 21:07:54 +0300 Bryan Sullivanlt;bls...@gmail.comgt; wrote Lisa, If you want to setup an adhoc discussion on your proposal, please let me know and I will join. Thanks, Bryan Sullivan On Apr 22, 2013 9:42 AM, Charles McCathie Nevile lt;cha...@yandex-team.rugt; wrote: Hi Lisa, On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman lt;lisa.see...@zoho.comgt; wrote: Over the weekend I put up a (very) draft outline for a roadmap for inclusion of people with cognitive disabilities. See http://athenatechnologies.org/RoadmapCog01.html. The most relivent part is probebly the specification suggestion at http://athenatechnologies.org/RoadmapCog01.html#specification. Do you think we should set some time at the FTF to see how WebAPPs can fit in? Hi Lisa, After talking to my co-chair, we believe are not ready to schedule WebApps time for this. The draft is at too early and too conceptual a stage so far. Web Apps generally works on a more or less concrete proposal for a given API or set of APIs (and assocaited markup as relevant). We don't think the group has the necessary expertise and understanding to be an effective place to develop the work from its current stage. If you will be at the meetings I encourage you to talk to *people* from Web Apps, and explain the direction you are working in, to see if they can offer insight or if you can offerit to them. But I think that at this stage you should be developing this further in WAI before coming back to Web Apps with a potential proposal for work. (There may be resistance there to some of the things you are aiming to do, but it is less than in other places, and there is more expertise there than in other parts of W3C). Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [admin] Testing and GitHub login names
On 19/04/2013 06:15 , Arthur Barstow wrote: Test Facilitators, Editors, All, If you intend to continue to participate in WebApps' testing effort or you intend to begin to participate, please send your GitHub login name to Robin (ro...@w3.org) so he can make sure you have appropriate access to WebApps' test directories. I would like to point out an important detail here: unless you want to review tests or to participate in the general shepherding of the test suite, you don't need to send me your GitHub login. More specifically, if you only plan to contribute tests, you don't need to send me anything: you already can. The way things works for contributors (irrespective of whether they have push access or not) is this: all contributions are made through pull requests. That's how we organise code review. The only thing that we ask is that pull requests not be merged by whoever made the request. So anyone with a GitHub account is already 100% set up to contribute. If you *do* wish to help with the reviewing and organisation effort, you're more than welcome to and I'll be happy to add you. I just wanted to make sure that people realise there's zero overhead for regular contributions. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges
michael.rou...@gmail.com wrote:
Hum ... thank you for this answer, but ...
Are you sure there is no possibility that the application is completed
before adding events?
I find it hard to perceive how it couldn't happen.
Do you also worry that if you wrote:
x = 0;
setTimeout(function() { x = 1; }, 0);
console.log(x);
console.log(x);
console.log(x);
console.log(x);
console.log(x);
console.log(x);
that there's a risk that you'd get a few 0's in the log, but at some
point it would switch to logging 1's?
No developer that I've talked to think that that could happen in JS.
And it can't. It's clear to everyone that you'll only get 0's. The
reason is that JS is single threaded and the setTimeout callback is
run asynchronously.
It's the same thing in IDB. The .onsuccess property is triggered
asynchronously which means that it couldn't happen in the middle of
your execution.
/ Jonas
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges michael.rou...@gmail.comwrote: Hum ... thank you for this answer, but ... Are you sure there is no possibility that the application is completed before adding events? I find it hard to perceive how it couldn't happen. Just to close the loop on this concern: the reason there is no possibility is that this part of the IndexedDB specification - all browsers must guarantee this behavior to have a working IndexedDB - in fact the rest of IndexedDB itself would be unusable if this guarantee was not met. Stuff like this can feel a little awkward if you're using to dealing in a multi-threaded world, but this API is fairly normal for a web api, at least in this respect. In fact XHR is the outlier here in requiring a specific xhrrequest.send() call. Alec
Re: [admin] Testing and GitHub login names
On 4/22/13 2:29 PM, ext Robin Berjon wrote: On 19/04/2013 06:15 , Arthur Barstow wrote: Test Facilitators, Editors, All, If you intend to continue to participate in WebApps' testing effort or you intend to begin to participate, please send your GitHub login name to Robin (ro...@w3.org) so he can make sure you have appropriate access to WebApps' test directories. I would like to point out an important detail here: unless you want to review tests or to participate in the general shepherding of the test suite, you don't need to send me your GitHub login. More specifically, if you only plan to contribute tests, you don't need to send me anything: you already can. The way things works for contributors (irrespective of whether they have push access or not) is this: all contributions are made through pull requests. That's how we organise code review. Yes, thanks for this clarification. The only thing that we ask is that pull requests not be merged by whoever made the request. Is this to prevent the `fox guarding the chicken coop`, so to speak? If a test facilitator submits tests (i.e. makes a PR) and everyone that reviews them says they are OK, it seems like the facilitator should be able to do the merge. (My apologies if I still don't quite understand all of the work flow here.) So anyone with a GitHub account is already 100% set up to contribute. If you *do* wish to help with the reviewing and organisation effort, you're more than welcome to and I'll be happy to add you. I just wanted to make sure that people realise there's zero overhead for regular contributions. Excellent. -AB
Re: [admin] Testing and GitHub login names
On Mon, 22 Apr 2013, Arthur Barstow wrote: The only thing that we ask is that pull requests not be merged by whoever made the request. Is this to prevent the `fox guarding the chicken coop`, so to speak? If a test facilitator submits tests (i.e. makes a PR) and everyone that reviews them says they are OK, it seems like the facilitator should be able to do the merge. Yes, my view is that Robin is trying to enforce the wrong condition here. The problem isn't with people merging their own changes; it's with unreviewed changes being merged. Unfortunately github doesn't naturally provide any way to track progress of a review and therefore there isn't any way to tell that review is complete. Just to signal the end of the review we could adopt some convention like leaving a comment Accepted to indicate that the reviewer believes that all commits have been fully reviewed and there are no further issues to be resolved. (as an aside, I note that critic does a much better job here. It allows reviewers to mark when they have completed reviewing each file in each commit. It also records exactly how each issue raised was resolved, either by the commit that fixed it or by the person that decided to mark the issue as resolved) So anyone with a GitHub account is already 100% set up to contribute. If you *do* wish to help with the reviewing and organisation effort, you're more than welcome to and I'll be happy to add you. I just wanted to make sure that people realise there's zero overhead for regular contributions. Indeed, there are currently 41 open pull requests and that number is not decreasing. Getting more help with the reviewing is essential. But that's a Hard Problem because reviewing is both difficult and boring.
Re: InedxedDB events : misconception?
On 4/22/13 4:36 PM, Joshua Bell wrote: The debugger spins the event loop Fwiw, that seems like a bug in the debugger (albeit a common one in browser debuggers) :( -Boris
Re: InedxedDB events : misconception?
Resending from the correct account:
FWIW, we had a Chrome IDB bug report where someone used the developer tools
to set a script breakpoint between the open() call and the event handler
assignments. The debugger spins the event loop, so the event was dispatched
before the handlers were assigned. The answer was so don't do that, but
it's a similar API/platform gotcha leading to developer confusion.
On Mon, Apr 22, 2013 at 10:36 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/22/13 1:31 PM, Tab Atkins Jr. wrote:
Is there a reason to not pass the success/error/upgradeneeded callbacks
in a
dictionary to open() in this case, so that the request object is born
with
the right bits and the actual reques it not kicked off until _after_ the
side-effects of getting them off the dictionary have fully run to
completion?
Dunno, ask sicking. But events do have some benefits over passed
callbacks.
I don't understand the distinction.
My straw-man proposal here is just that there is a dictionary with the
three callbacks and then the return value has its
onsuccess/onerror/**onupgradeneeded
set to those three callbacks before the actual request is kicked off and
the request object is returned.
(The right answer is to figure out some way to accommodate IDB's
locking semantics in a future. sicking and annevk have some
discussion on this. Then there's no possibility of event races,
because your callback will still be fired even if you lose the race.)
That would be good, yes.
Given the upgradeneeded mechanism, it might end up being a hybrid of
passed-callbacks and futures, e.g.
futureSavvyIndexedDB.open(name, ver, {
upgradeneeded: function(db) { /* upgrade logic */ }
).then(
function(db) { /* success */ },
function(err) { /* failure */ }
);
... with blocked events wedged in there somehow as future progress
notifications or some such. (I haven't followed the latest on that.)
Synchronously spinning the event loop is the devil. :/
Well, yes. ;)
-Boris
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 1:50 PM, Joshua Bell jsb...@chromium.org wrote: FWIW, we had a Chrome IDB bug report where someone used the developer tools to set a script breakpoint between the open() call and the event handler assignments. The debugger spins the event loop, so the event was dispatched before the handlers were assigned. The answer was so don't do that, but it's a similar API/platform gotcha leading to developer confusion. I would claim that's an implementation bug. - Kyle
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 1:57 PM, Kyle Huey m...@kylehuey.com wrote: On Mon, Apr 22, 2013 at 1:50 PM, Joshua Bell jsb...@chromium.org wrote: FWIW, we had a Chrome IDB bug report where someone used the developer tools to set a script breakpoint between the open() call and the event handler assignments. The debugger spins the event loop, so the event was dispatched before the handlers were assigned. The answer was so don't do that, but it's a similar API/platform gotcha leading to developer confusion. I would claim that's an implementation bug Agreed, and apologies for implying I felt otherwise otherwise. To clarify: don't do that until the debugger architecture is changed. (Also, apologies if you get this more or less than one time. I'm trying to switch my mailing list subscription over to my @google.com account but hitting a list server problem.)
RE: MathML and Clipboard API and events
Web Applications Working Group, Greetings. In addition to facilitating interprocess communication, clipboarding, with the data of arbitrary selections of hypertext and MathML, the aforementioned techniques can facilitate interprocess communication with the data of arbitrary selections of hypertext with RDFa, content in the formats of hypertext, RDF, and hypertext with RDFa. Kind regards, Adam Sobieski From: adamsobie...@hotmail.com To: public-webapps@w3.org CC: hallv...@opera.com Date: Sat, 20 Apr 2013 19:40:48 + Subject: RE: MathML and Clipboard API and events Web Applications Working Group, Greetings. With regard to MathML and clipboard API and events, some clipboarding and interprocess communication API topics include: (1) The use of JavaScript callback functions or interfaces with the DataTransfer interface (http://www.w3.org/TR/html5/editing.html#the-datatransfer-interface); WebIDL includes syntax for callback functions (http://www.w3.org/TR/WebIDL/#dfn-callback-function) and interfaces (http://www.w3.org/TR/WebIDL/#dfn-callback-interface). An earlier letter discussing the topic was RE: [Clipboard] Mathematical Proofs in HTML5 Documents (http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0041.html). (2) The use of XInclude (http://www.w3.org/TR/xinclude/) in clipboarding and interprocess communication with RFC2392 (http://www.ietf.org/rfc/rfc2392.txt) in such a way that clipboard content with such XML can be differentiated from from clipboard-related uses of such XML. (3) Provenance data interoperable with bibliographic referencing systems and document authoring software in clipboarding and interprocess communication. A solution for clipboarding arbitrary selections of hypertext which can include MathML, which can include parallel markup, is the use of XInclude in the clipboarded hypertext. In addition to backwards compatible clipboarding, with text/html and application/xhtml+xml, we could also utilize content type parameters, for instance text/html; ...=... and application/xhtml+xml; ...=..., which could indicate to clipboard consumers the use of XInclude and RFC2392 in interprocess communication. That is, from an arbitrary selection of hypertext document content including: pThis sentence has mathematics in it math ../math./p we can envision something on the clipboard like: pThis sentence has mathematics in it include xmlns=http://www.w3.org/2001/XInclude; href=... /./p where the URI scheme of the XInclude's @href could be as per RFC2392 so as to indicate content from another clipboard resource, which could have a multipart/alternative content type, and content types such as: application/mathml-presentation+xml, application/mathml-content+xml, and/or application/mathml+xml, as well as other formats and content based upon processing any parallel content (http://www.w3.org/TR/MathML3/chapter5.html) in the MathML. Pasting would then be a bit more complex, scanning for such XInclude elements, and assembling content utilizing formats known to the pasting application. Kind regards, Adam Sobieski
Re: InedxedDB events : misconception?
On Mon, Apr 22, 2013 at 12:32 PM, Alec Flett alecfl...@chromium.org wrote: On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges michael.rou...@gmail.comwrote: Hum ... thank you for this answer, but ... Are you sure there is no possibility that the application is completed before adding events? I find it hard to perceive how it couldn't happen. Just to close the loop on this concern: the reason there is no possibility is that this part of the IndexedDB specification - all browsers must guarantee this behavior to have a working IndexedDB - in fact the rest of IndexedDB itself would be unusable if this guarantee was not met. Stuff like this can feel a little awkward if you're using to dealing in a multi-threaded world, but this API is fairly normal for a web api, at least in this respect. In fact XHR is the outlier here in requiring a specific xhrrequest.send() call. Yeah, there's a bunch of APIs like this; EventSource, Notification, IndexDB's stuff, ... - E
Re: InedxedDB events : misconception?
Ok, the example of console.log () has made me realize something I had never seen that. In short, if I understood from my tests, asynchronous instruction is executed at the earliest, after the last statement of the scope in which it is declared. There was a misconception ... in my mind. Please apologize for the inconvenience. Cordially, Michaël
Re: InedxedDB events : misconception?
Oh, sorry... and thank you all for your explanations. :)
