On Wed, Feb 20, 2008 at 3:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
If XMLHttpRequest is one of the APIs available on background threads,
does that include its XML parsing/serialization features (responseXML
and the ability to pass a Document as the post data)? If so, then
effectively
On Thu, Feb 14, 2008 at 5:44 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] wrote:
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
On Tue, Feb 19, 2008 at 2:58 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
Given that most people don't know the difference between the Window and
the global object and the global worker object will already contain a
bunch of APIs identical to those on the Window object it seems to me that
On Tue, 19 Feb 2008 22:46:44 +0100, Scott Hess [EMAIL PROTECTED] wrote:
It seems to me that this is an area where if you give an inch, the
developer wants another inch. If you have something called window,
then you're just moving things around - instead of saying Where is my
window?, developers
On Feb 19, 2008, at 2:57 PM, Aaron Boodman wrote:
On Tue, Feb 19, 2008 at 2:58 PM, Anne van Kesteren
[EMAIL PROTECTED] wrote:
Given that most people don't know the difference between the Window
and
the global object and the global worker object will already contain a
bunch of APIs
On Tue, Feb 19, 2008 at 6:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
If XMLHttpRequest is one of the APIs available on background threads,
does that include its XML parsing/serialization features (responseXML
and the ability to pass a Document as the post data)? If so, then
Geoff,
These are all good questions.
I apologize, this was a spur-of-the-moment
write-down-before-it-goes-away post. And as such, it's skimp on the
meat. If anything, it was a good enough nudge for Aaron and Hixie to
release their proposals.
What I did want to capture is the idea of API
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
capabilities:
WorkerWindow openWorker(in DOMString url);
with:
interface WorkerWindow {
Well, as long as you've brought it up, I was working on a proposal too:
http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal
- a
On Thu, Feb 14, 2008 at 11:34 AM, Dimitri Glazkov
[EMAIL PROTECTED] wrote:
Since postMessage API is looking more an more like the Gears worker
messaging
LOL. Who else has been quietly concocting a worker spec?
This very much along the lines of what I was thinking. Equating worker
to (or drawing parallels with) a window object is the approach that
would make workers easier to understand for developers, IMHO.
I am not quite sure yet about DOM
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
capabilities:
Why call these windows at all? They seem to have no relationship
physical
On Thu, Feb 14, 2008 at 11:34 AM, Dimitri Glazkov
[EMAIL PROTECTED] wrote:
// caps
readonly attribute ClientInformation navigator;
I forgot about navigator in my proposal. That is another one that has
been asked for in Gears workers. Added!
- a
On Thu, 14 Feb 2008, Aaron Boodman wrote:
Well, as long as you've brought it up, I was working on a proposal too:
http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal
As was I. :-)
http://www.hixie.ch/specs/dom/workers/0.9
--
Ian Hickson U+1047E
On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] wrote:
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
14 matches
Mail list logo
