Re: [admin] Testing and GitHub login names

[Robin Berjon]

On 22/04/2013 13:12 , James Graham wrote:

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.


No, I'm just operating under different assumptions. As I said before, if 
someone wants to review without having push/merge powers, it's perfectly 
okay. I don't even think we need a convention for it (at this point). I 
do however consider that this is an open project, so that whoever 
reviews tests can be granted push/merge power.


Why? Because the alternative is this: you get an "accepted" comment from 
someone on a PR. Either you trust that person, in which case she could 
have merge powers; or you don't, in which case you have to review the 
review to check that it's okay. Either way, we're better off making that 
decision at the capability assignment level since it only happens once 
per person.



The problem isn't with people merging their own changes; it's with
unreviewed changes being merged.


Yup.


(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)


You may wish to introduce Critic a bit more than that; I'm pretty sure 
that many of the bystanders in this conversation aren't conversant with it.



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.


I would qualify that statement. If you're already pretty good with web 
standards and you wish to improve your understanding to top levels (and 
gain respect from your peers), this is actually a really good thing to 
work on. Or if you're implementing, it's likely a little bit less work 
to review than to write from scratch (and it can make you aware of 
corner cases or problems you hadn't thought of). Put differently, I 
think it can be a lot less boring if you're getting something out of it.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [admin] Testing and GitHub login names

[Robin Berjon]

On 22/04/2013 12:44 , 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?


The way you put it ascribes malice, whereas we operate on the assumption 
that people are honest and trustworthy. This is different from the 
previous rules whereby you couldn't review tests from someone working in 
the same company as yourself. I'm pretty sure that people here are 
indeed honest, and at any rate if they aren't the cost in lost 
credibility along with the quasi-certainty of being caught when another 
vendor notices a problem with the tests ought to make them behave as if 
they were :)


What we're trying to prevent is more "every terribly sucks at noticing 
their own typos".



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.


Of course. If you submit a PR with tests and someone who doesn't happen 
to have push powers has okayed them, then you should just merge them 
with a comment to the effect that such and such has found them to be 
good. The point is to get some eyeballs that aren't the author's to look 
at the tests before they go in; whatever process makes that happen is 
good so long as it does not involve bureaucracy.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: InedxedDB events : misconception?

[Michaël Rouges]

Oh, sorry... and thank you all for your explanations. :)

Re: InedxedDB events : misconception?

[Michaël Rouges]

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?

[Elliott Sprehn]

On Mon, Apr 22, 2013 at 12:32 PM, Alec Flett  wrote:

> On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges 
> 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.
>>
>
> 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: MathML and "Clipboard API and events"

[Adam Sobieski]

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:



This
 sentence has mathematics in it 



we can envision something on the clipboard like:



This sentence has mathematics in it http://www.w3.org/2001/XInclude"; href="..." />.



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?

[Joshua Bell]

On Mon, Apr 22, 2013 at 1:57 PM, Kyle Huey  wrote:

> On Mon, Apr 22, 2013 at 1:50 PM, Joshua Bell  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: InedxedDB events : misconception?

[Kyle Huey]

On Mon, Apr 22, 2013 at 1:50 PM, Joshua Bell  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?

[Joshua Bell]

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  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?

[Boris Zbarsky]

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: [admin] Testing and GitHub login names

[James Graham]

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: [admin] Testing and GitHub login names

[Arthur Barstow]

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: InedxedDB events : misconception?

[Alec Flett]

On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges 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.
>

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: InedxedDB events : misconception?

[Jonas Sicking]

On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges
 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: [admin] Testing and GitHub login names

[Robin Berjon]

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: roadmap for inclusion of people with cognitive disabilities

[lisa.seeman]

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 Sullivan 
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" 
 wrote:
 Hi Lisa,
 
 On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman  
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: InedxedDB events : misconception?

[Boris Zbarsky]

On 4/22/13 1:41 PM, Tab Atkins Jr. wrote:

On Mon, Apr 22, 2013 at 10:36 AM, Boris Zbarsky  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

[Bryan Sullivan]

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" 
wrote:

> Hi Lisa,
>
> On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman 
> 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: InedxedDB events : misconception?

[Tab Atkins Jr.]

On Mon, Apr 22, 2013 at 10:36 AM, Boris Zbarsky  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: InedxedDB events : misconception?

[Boris Zbarsky]

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?

[Tab Atkins Jr.]

On Mon, Apr 22, 2013 at 10:17 AM, Boris Zbarsky  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?

[Michaël Rouges]

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?

[Boris Zbarsky]

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?

[Tab Atkins Jr.]

On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges
 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?

[Michaël Rouges]

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?

[Tab Atkins Jr.]

On Mon, Apr 22, 2013 at 9:43 AM, Michaël Rouges
 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

InedxedDB events : misconception?

[Michaël Rouges]

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: roadmap for inclusion of people with cognitive disabilities

[Charles McCathie Nevile]

Hi Lisa,

On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman   
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: For a deeper Indexed Database API (nested ObjectStores)

[Michaël Rouges]

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: For a deeper Indexed Database API (nested ObjectStores)

[Eric Bidelman]

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 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  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();
>
> ** **
>
> 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 
> Member
>
> http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
> Github  | BitBucket 
> 
>
> ** **
>
> *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

RE: For a deeper Indexed Database API (nested ObjectStores)

[Aaron Powell]

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();

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 
Member

http://apowell.me | http://twitter.com/slace | Skype: 
aaron.l.powell | Github | 
BitBucket

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

For a deeper Indexed Database API (nested ObjectStores)

[Michaël Rouges]

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