RE: [IndexedDB] Throwing when *creating* a transaction
IE is okay with removing this from the spec.
Israel
On Monday, October 31, 2011 5:06 PM, Joshua Bell wrote:
From: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell
Sent: Monday, October 31, 2011 5:06 PM
To: Webapps WG
Subject: Re: [IndexedDB] Throwing when *creating* a transaction
On Mon, Oct 31, 2011 at 3:02 PM, Jonas Sicking
mailto:jo...@sicking.cc>> wrote:
Hi guys,
Currently the spec contains the following sentence:
"Conforming user agents must automatically abort a transaction at the
end of the scope in which it was created, if an exception is
propagated to that scope."
This means that the following code:
setTimeout(function() {
doStuff();
throw "booo";
}, 10);
function doStuff() {
var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
trans.objectStore("store1").put({ some: "value" }, 5);
}
is supposed to abort the transaction. I.e. since the same callback (in
this case a setTimeout callback) which created the transaction later
on throws, the spec says to abort the transaction. This was something
that we debated a long time ago, but my recollection was that we
should not spec this behavior. It appears that this was never removed
from the spec though.
One reason that I don't think that we should spec this behavior is
that it's extremely tedious and error prone to implement. At every
point that an implementation calls into javascript, the implementation
has to add code which checks if an exception was thrown and if so,
check if any transactions were started, and if so abort them.
I'd like to simply remove this sentence. Any objections?
No objections here. Chrome doesn't currently implement this behavior.
Note, this does *not* affect the aborting that happens if an exception
is thrown during a "success" or "error" event handler.
/ Jonas
Re: QSA, the problem with ":scope", and naming
On 10/31/11 9:32 PM, Charles Pritchard wrote:
Structured cloning fails for NodeList, same as postMessage, because of
circular structure.
What circular structure? Structured clone can handle that.
It fails because it's a host object (based on its [[Class]]) that's not
whitelisted in the structured clone algorithm.
With .join, you get the .toString of the DOM Nodes.
Yes, as you would for an array of DOM nodes.
A quick skim through the ES spec shows that Array.prototype.concat also
considers the [[Class]] of its arguments, by the way. And indeed, this
testcase:
var l = document.getElementsByTagName("html");
var a = Array.prototype.slice.call(l);
l.__proto__.__proto__ = Array.prototype;
var test1 = [].concat(l);
var test2 = [].concat(a);
alert(test1[0] instanceof HTMLHtmlElement);
alert(test2[0] instanceof HTMLHtmlElement);
alerts "false" followed by "true" in UAs.
So we really do need to decide what it means for a return value to "be
an Array". For example, how does it behave with concat()?
-Boris
Re: QSA, the problem with ":scope", and naming
On 10/31/11 7:25 PM, Alex Russell wrote: For JS, it just means having a working ".length" property (in all the ways that Arrays allow it to be used). Arrays are identical to other objects in all other respects. No, they're not. For example, off the top of my head, they get serialized differently by JSON.stringify. Note that this is based off of the [[Class]] (ES5 section 15.12.3 definition of Str() item 10a). So if you want your object to behave like an array for JSON serialization, it needs to have the right [[Class]]. I'd bet money there are other such things in ES5, for what it's worth. Structured cloning fails for NodeList, same as postMessage, because of circular structure. With .join, you get the .toString of the DOM Nodes. There is no JSON serialization for DOM elements.
Re: QSA, the problem with ":scope", and naming
On 10/31/11 7:25 PM, Alex Russell wrote: For JS, it just means having a working ".length" property (in all the ways that Arrays allow it to be used). Arrays are identical to other objects in all other respects. No, they're not. For example, off the top of my head, they get serialized differently by JSON.stringify. Note that this is based off of the [[Class]] (ES5 section 15.12.3 definition of Str() item 10a). So if you want your object to behave like an array for JSON serialization, it needs to have the right [[Class]]. I'd bet money there are other such things in ES5, for what it's worth. We'll need ES 6 proxies to get the working .length thing today. Not ideal. I think we should just start assuming ES 6 proxies or equivalent mechanism. It's needed for all sorts of stuff and UAs are implementing it anyway. If we want to avoid assuming it, we could just specify things in terms of ES5 internal classes and hooks. -Boris
Re: [IndexedDB] Throwing when *creating* a transaction
On Mon, Oct 31, 2011 at 3:02 PM, Jonas Sicking wrote:
> Hi guys,
>
> Currently the spec contains the following sentence:
>
> "Conforming user agents must automatically abort a transaction at the
> end of the scope in which it was created, if an exception is
> propagated to that scope."
>
> This means that the following code:
>
> setTimeout(function() {
> doStuff();
> throw "booo";
> }, 10);
>
> function doStuff() {
> var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
> trans.objectStore("store1").put({ some: "value" }, 5);
> }
>
> is supposed to abort the transaction. I.e. since the same callback (in
> this case a setTimeout callback) which created the transaction later
> on throws, the spec says to abort the transaction. This was something
> that we debated a long time ago, but my recollection was that we
> should not spec this behavior. It appears that this was never removed
> from the spec though.
>
> One reason that I don't think that we should spec this behavior is
> that it's extremely tedious and error prone to implement. At every
> point that an implementation calls into javascript, the implementation
> has to add code which checks if an exception was thrown and if so,
> check if any transactions were started, and if so abort them.
>
> I'd like to simply remove this sentence. Any objections?
>
No objections here. Chrome doesn't currently implement this behavior.
> Note, this does *not* affect the aborting that happens if an exception
> is thrown during a "success" or "error" event handler.
>
> / Jonas
>
>
Re: QSA, the problem with ":scope", and naming
On Mon, Oct 31, 2011 at 2:18 PM, Charles Pritchard wrote:
> On 10/31/11 2:03 PM, Cameron McCormack wrote:
>>
>> On 31/10/11 1:56 PM, Alex Russell wrote:
>>>
>>> Live NodeList instances don't need to be considered here. They're the
>>> result of an API which generates them, and that API can be described
>>> in terms of Proxies. No need to complicate NodeList or imply that we
>>> need a different type.
>>>
>>> Making NodeList instances real array unifies them all. We can get that
>>> done too.
>>
>> Don't live and static NodeLists use the same prototype? If they are
>> separate, I don't see any problem with making them "real arrays", but I am
>> not sure what the implications of that are. Array.isArray == true, I guess?
>> Do we have that ability within the bounds of ECMAScript yet? Note that we
>> can already make NodeList.prototype === Array.prototype if we want, using
>> appropriate Web IDL annotations.
>
> Array seems to work fine in WebKit:
> document.getElementsByTagName('div').__proto__.__proto__ = Array.prototype;
>
> dojo just reimplements NodeList as an array:
> http://dojotoolkit.org/reference-guide/dojo/NodeList.html
The reason we did it that way is because there's no other way to
create an intermediate type with the magic ".length" property.
> I don't understand what "real array" means, other than the prototype
> equivalence.
>
> If NodeList were an array, what's the behavior of running push on NodeList?
> The list may end up with non-node objects if push is not supplemented.
>
> -Charles
>
>
>
Re: QSA, the problem with ":scope", and naming
On Mon, Oct 31, 2011 at 2:03 PM, Cameron McCormack wrote: > On 31/10/11 1:56 PM, Alex Russell wrote: >> >> Live NodeList instances don't need to be considered here. They're the >> result of an API which generates them, and that API can be described >> in terms of Proxies. No need to complicate NodeList or imply that we >> need a different type. >> >> Making NodeList instances real array unifies them all. We can get that >> done too. > > Don't live and static NodeLists use the same prototype? Yes, I envision they would. The restrictions on live lists are probably going to be created by a proxy that wraps them and manages their semantics. > If they are > separate, I don't see any problem with making them "real arrays", but I am > not sure what the implications of that are. Array.isArray == true, I guess? For JS, it just means having a working ".length" property (in all the ways that Arrays allow it to be used). Arrays are identical to other objects in all other respects. > Do we have that ability within the bounds of ECMAScript yet? Note that we > can already make NodeList.prototype === Array.prototype if we want, using > appropriate Web IDL annotations. We'll need ES 6 proxies to get the working .length thing today. Not ideal.
[Bug 14474] Make it possible to close a connection in such a manner that all subsequent events are suppressed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14474 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 14592] EventSource should default to use "Use Credentials" set to false for CORS
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14592 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 14322] Update URL of the WebSocket protocol
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14322 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Ian 'Hixie' Hickson 2011-10-31 22:48:47 UTC --- *** This bug has been marked as a duplicate of bug 13700 *** -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 12510] Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12510 Ian 'Hixie' Hickson changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #11 from Ian 'Hixie' Hickson 2011-10-31 22:47:58 UTC --- I have no intention of adding cross-spec cross-references to the WebSocket spec. If someone is interested in providing patches to the spec splitter to do this, please contact me directly. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: QSA, the problem with ":scope", and naming
On 31/10/11 2:18 PM, Charles Pritchard wrote: I don't understand what "real array" means, other than the prototype equivalence. There's also the [[DefineOwnProperty]] behaviour which is different from normal objects. That kind of behaviour doesn't *need* to be handled by making NodeLists "real arrays", it can be done by making them proxies. Some people might prefer not to do require that though, if it is indeed possible to make them real arrays.
[IndexedDB] Throwing when *creating* a transaction
Hi guys,
Currently the spec contains the following sentence:
"Conforming user agents must automatically abort a transaction at the
end of the scope in which it was created, if an exception is
propagated to that scope."
This means that the following code:
setTimeout(function() {
doStuff();
throw "booo";
}, 10);
function doStuff() {
var trans = db.transaction(["store1"], IDBTransaction.READ_WRITE)
trans.objectStore("store1").put({ some: "value" }, 5);
}
is supposed to abort the transaction. I.e. since the same callback (in
this case a setTimeout callback) which created the transaction later
on throws, the spec says to abort the transaction. This was something
that we debated a long time ago, but my recollection was that we
should not spec this behavior. It appears that this was never removed
from the spec though.
One reason that I don't think that we should spec this behavior is
that it's extremely tedious and error prone to implement. At every
point that an implementation calls into javascript, the implementation
has to add code which checks if an exception was thrown and if so,
check if any transactions were started, and if so abort them.
I'd like to simply remove this sentence. Any objections?
Note, this does *not* affect the aborting that happens if an exception
is thrown during a "success" or "error" event handler.
/ Jonas
Re: QSA, the problem with ":scope", and naming
Ok, so we're down to not having full agreement on the following selectors:
On Mon, Oct 31, 2011 at 1:55 PM, Alex Russell wrote:
> On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking wrote:
>> e.findAll("body > :scope > div")
>
> 1, 2, 3, 4
>
>> e.findAll("body > :scope > div, :scope")
>
> context, 1, 2, 3, 4
I'm hoping that you just made a mistake here? 4 isn't a child of the
context node. So in both of these I would think that 4 should be
removed based on your answers to the other questions.
>> e.findAll("div, :scope")
>
> context, 1, 2, 3, 4
Yehuda had a very different suggestion here but so far hasn't motivated why.
Personally I think Alex answer is the more useful one.
We just need to decide on something
>> e.findAll(":not(:scope)")
>
> empty set
Again, Yehuda had a different answer here. Though in this case I think
Yehuda's answer is more useful and consistent.
But I'm all ears for what the logic used to get to your answer and why
you think this is a better (more consistent? more useful?) answer.
/ Jonas
Re: QSA, the problem with ":scope", and naming
On 10/31/11 2:03 PM, Cameron McCormack wrote:
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be described
in terms of Proxies. No need to complicate NodeList or imply that we
need a different type.
Making NodeList instances real array unifies them all. We can get
that done too.
Don't live and static NodeLists use the same prototype? If they are
separate, I don't see any problem with making them "real arrays", but
I am not sure what the implications of that are. Array.isArray ==
true, I guess? Do we have that ability within the bounds of
ECMAScript yet? Note that we can already make NodeList.prototype ===
Array.prototype if we want, using appropriate Web IDL annotations.
Array seems to work fine in WebKit:
document.getElementsByTagName('div').__proto__.__proto__ = Array.prototype;
dojo just reimplements NodeList as an array:
http://dojotoolkit.org/reference-guide/dojo/NodeList.html
I don't understand what "real array" means, other than the prototype
equivalence.
If NodeList were an array, what's the behavior of running push on NodeList?
The list may end up with non-node objects if push is not supplemented.
-Charles
Re: QSA, the problem with ":scope", and naming
On 31/10/11 1:56 PM, Alex Russell wrote: Live NodeList instances don't need to be considered here. They're the result of an API which generates them, and that API can be described in terms of Proxies. No need to complicate NodeList or imply that we need a different type. Making NodeList instances real array unifies them all. We can get that done too. Don't live and static NodeLists use the same prototype? If they are separate, I don't see any problem with making them "real arrays", but I am not sure what the implications of that are. Array.isArray == true, I guess? Do we have that ability within the bounds of ECMAScript yet? Note that we can already make NodeList.prototype === Array.prototype if we want, using appropriate Web IDL annotations.
Re: QSA, the problem with ":scope", and naming
On Sun, Oct 30, 2011 at 1:23 PM, Rick Waldron wrote: > > > On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack wrote: >> >> On 20/10/11 3:50 AM, Alex Russell wrote: >>> >>> I strongly agree that it should be an Array *type*, but I think just >>> returning a plain Array is the wrong resolution to our NodeList >>> problem. WebIDL should specify that DOM List types *are* Array types. >>> It's insane that we even have a NodeList type which isn't a real array >>> at all. Adding a parallel system when we could just fix the one we >>> have (and preserve the value of a separate prototype for extension) is >>> wonky to me. >>> >>> That said, I'd *also* support the ability to have some sort of >>> decorator mechanism before return on .find() or a way to re-route the >>> prototype of the returned Array. >>> >>> +heycam to debate this point. >> >> Late replying here again, apologies, but I agree with others who say that >> an actual Array object should be returned from this new API given that it is >> not meant to be live. What benefit is there from returning a NodeList? > > As much as I hate saying this: introducing a third return type would be > counter-productive, as you'd now have live NodeList, static NodeList and > subclassed Array. Congratulations, the cluster-f*ck continues in true form. Live NodeList instances don't need to be considered here. They're the result of an API which generates them, and that API can be described in terms of Proxies. No need to complicate NodeList or imply that we need a different type. Making NodeList instances real array unifies them all. We can get that done too.
Re: QSA, the problem with ":scope", and naming
What Tab said = ) On Sun, Oct 30, 2011 at 9:23 AM, Tab Atkins Jr. wrote: > On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack wrote: >> On 20/10/11 3:50 AM, Alex Russell wrote: >>> >>> I strongly agree that it should be an Array *type*, but I think just >>> returning a plain Array is the wrong resolution to our NodeList >>> problem. WebIDL should specify that DOM List types *are* Array types. >>> It's insane that we even have a NodeList type which isn't a real array >>> at all. Adding a parallel system when we could just fix the one we >>> have (and preserve the value of a separate prototype for extension) is >>> wonky to me. >>> >>> That said, I'd *also* support the ability to have some sort of >>> decorator mechanism before return on .find() or a way to re-route the >>> prototype of the returned Array. >>> >>> +heycam to debate this point. >> >> Late replying here again, apologies, but I agree with others who say that an >> actual Array object should be returned from this new API given that it is >> not meant to be live. What benefit is there from returning a NodeList? > > If it's a NodeList (or something else that *subclasses* Array) we can > do fun things like add .find to it, which returns the sorted union of > calling .find on all the elements within it. Returning a plain Array > doesn't let us do that. > > ~TJ >
Re: QSA, the problem with ":scope", and naming
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking wrote:
> On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt
> wrote:
>> Not necessarily. It depends what exactly it means for a selector to
>> contain
>> :scope for determining whether or not to enable the implied :scope
>> behaviour. Consider:
>>
>> foo.find(":not(:scope)");
>
> Ooh, this is an interesting case too. So here's the full list of cases which
> we need defined behavior for (again looking at Alex and Yehuda here).
>
> In the following DOM
>
>
>
>
>
>
>
>
>
>
>
>
> What would each of the following .findAll calls return. I've included my
> guessed based on the discussions so far:
>
> var e = document.getElementById('context');
>
> e.findAll("div") // returns ids 1,2,3,4
> e.findAll("") // returns an empty list
> e.findAll("#3") // returns id 3, but not the body node
> e.findAll("> div") // returns ids 1,2,3
> e.findAll("[foo=bar]") // returns nothing
> e.findAll("[id=1]") // returns id 1
> e.findAll(":first-child") // returns id 1
> e.findAll("+ div") // returns id 5
> e.findAll("~ div") // returns id 5, 6
> e.findAll(":scope")
Returns the context.
> e.findAll("div:scope")
Returns the context.
> e.findAll("[foo=bar]:scope")
Returns the context.
> e.findAll(":scope div")
1, 2, 3, 4
> e.findAll("div:scope div")
1, 2, 3, 4
> e.findAll("div:scope #3")
3
> e.findAll("body > :scope > div")
1, 2, 3, 4
> e.findAll("div, :scope")
context, 1, 2, 3, 4
> e.findAll("body > :scope > div, :scope")
context, 1, 2, 3, 4
> e.findAll(":not(:scope)")
empty set
Re: Enable compression of a blob to .zip file
On 10/31/11 11:34 AM, Boris Zbarsky wrote: On 10/31/11 1:42 PM, Charles Pritchard wrote: I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. I don't believe it is. In fact, doing that would contradict the specs as they stand, to my knowledge. I could be wrong, of course, but in that case citation needed... -Boris Well I've failed to find a citation. I will post one if I find it. In the meantime: Blob and Data uris can and should have sniffing for image/svg+xml. It's trivial, and it makes a whole lot more sense than extending both the Blob and data uri specs to include transfer encoding semantics. file: and filesystem: and widget urls are items that -might- be supported on an OS level, and thus out of scope here. Back to deflate use cases: PDF.js I'm sure implements deflate (for PDF FlateEncode), I've recently done some docx work which required deflate. Many servers do not host .svgz files well, and I use XHR with deflate to deal with that (though I would have just used blob urls if they worked). localStorage, indexedDB and WebSQL all require DOMString, as do most WebSocket implementations -- in practical use, this means base64 encoding data. It's another area where deflate could squeeze a few more bytes out of existing constraints. Especially with localStorage. As we continue to support more-and-more document formats, deflate support on the client side becomes more important. Apple and MS, two very large vendors, have pushed ahead with using deflate in various file formats they use. Adobe has been doing it for some time. Though HTTP works quite well for negotiated compression there are more and more cases that are not http bound. I would very much like to see deflate and inflate exposed to the scripting environment. From there I can easily interact with several file formats. Zip included. -Charles -Charles
WebSocket treated as subresource: no HTTP auth dialogs?
On a different thread, Adam Barth clarified that WebSocket connections
established
from JS should be treated as "subresources" in the context of the JS containing
page.
As a consequence, no browser built-in dialogs should be rendered which offer
the user a chance to act upon i.e. untrusted TLS server certificates when the
WebSocket connection is via TLS ("wss").
Now, how does that translate to HTTP authentication?
What if the WS connection requires HTTP authentication? When the WS is treated
as a subresource, does that mean that no authentication dialog should be
presented to the user for that?
Note, that this is a problem only when the WS connection is to a different
host/port than the JS containing page was served from, which might be
quite common in practice.
However, should above be the case ("no auth dialog rendered"), that may come
as a surprise to some in the WS community, since all discussions for WS auth
mechanisms were always ended by: "you have any HTTP auth there if you need".
The same question applies to HTTP basic/digest auth as well as TLS client cert
auth.
No dialog?
Re: Enable compression of a blob to .zip file
On 10/31/11 1:42 PM, Charles Pritchard wrote: I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. I don't believe it is. In fact, doing that would contradict the specs as they stand, to my knowledge. I could be wrong, of course, but in that case citation needed... -Boris
Re: Enable compression of a blob to .zip file
On 31/10/11 10:50 AM, Mike Hanson wrote: Work in progress: http://mimesniff.spec.whatwg.org/ There's a section on Images in there which looks like it won't do sniffing for automatic gunzipping. Although perhaps if the SVG document were used as the top level document it would be, if it falls under the Web Pages case.
Re: Enable compression of a blob to .zip file
On Oct 31, 2011, at 10:42 AM, Charles Pritchard wrote: > On 10/30/2011 5:56 PM, Cameron McCormack wrote: >> On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote: >>> Then he probably means file system files and not HTTP files, and support >>> there has indeed been spotty in the past. >> >> Ah, yes. Regarding data: URIs, someone should really just amend the RFC to >> allow specifying a content encoding. >> > > That seems rather unnecessary. > > I'm almost certain that somewhere, it is specified that the browser should > sniff the first few bytes of the file to see > if it is compressed. It's minimal work. Work in progress: http://mimesniff.spec.whatwg.org/ mh
Re: Enable compression of a blob to .zip file
On 10/30/2011 5:56 PM, Cameron McCormack wrote: On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote: Then he probably means file system files and not HTTP files, and support there has indeed been spotty in the past. Ah, yes. Regarding data: URIs, someone should really just amend the RFC to allow specifying a content encoding. That seems rather unnecessary. I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. It's minimal work. This also applies to the local file system; as in file:///.
FW: TPAC Web App
From: ext Dominique Hazael-Massieux [d...@w3.org] Sent: Monday, October 31, 2011 9:25 AM To: w...@w3.org; cha...@w3.org Subject: TPAC Web App Dear all, For those of you at TPAC, you may want to use the companion Web app to the event available at: http://www.w3.org/2011/11/TPAC/live/ and let others know about it. That Web app lets you access the schedule of the week, pick which meetings you plan on attending to build your own schedule, and let others know in what meetings room you are currently setting via "check-in", as well as orient yourself in the meeting facilities. It also features the list of registrants and their organizations to facilitate establishing contacts. This is very much an alpha-release of the tool, but we hope that you'll find useful during the week; learn more about the tool and the team behind it at http://www.w3.org/2011/11/TPAC/live/about Dom
Discussion topic for Webapps F2F on Nov 1
Hi Art and Chaals,
If possible (depending upon the Webapps agenda fullness) I would like
to propose a 30-60 minute discussion on followup work we have been
pursuing on extending Server-Sent Events for support of Connectionless
Push, as noted in the current SSE draft (the section
http://dev.w3.org/html5/eventsource/#eventsource-push, which resulted
from the last discussion we had on this in Webapps in the 2009 TPAC).
If there is time for this (at least 30 minutes) I can send info in
advance tomorrow, which will describe some approaches we have been
considering, including:
- adding support for additional URI schemes for eventsource, to
indicate additional bearers ("sources") for eventsource events
- processing of events from connectionless Push bearers (SMS, OMA
Push/SMS, and OMA Push in general) using the text/event-stream
processing model
- alternatively, using device-local eventsource server addresses as a
way to seamlessly extend eventsource for these additional bearers,
without impacting the browser
- any other ideas that Webapps members might have on how this can be
achieved with as much consistency with eventsource as possible (even
complete transparency, if possible)
This would be in essence a kickoff discussion of this in Webapps, if
the group overall thinks any of the ideas are well-formed enough to
pursue in some spec form.Otherwise the feedback would be useful
anyway, to help improve the API extension concepts and prototypes we
have been developing for submission to Webapps at the right time.
--
Thanks,
Bryan Sullivan
