[Bug 15554] New: Hi, The article is very good. Also user can view. HTML5 Web Workers http://www.totaldotnet.com/Article/ShowArticle145_HTML5WebWorker.aspx

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15554

   Summary: Hi, The article is very good. Also user can view.
HTML5 Web Workers
http://www.totaldotnet.com/Article/ShowArticle145_HTML
5WebWorker.aspx
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Workers (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/workers/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Hi,

The article is very good. Also user can view.
HTML5 Web Workers
http://www.totaldotnet.com/Article/ShowArticle145_HTML5WebWorker.aspx

Posted from: 1.23.229.131
User agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

-- 
Configure bugmail: https://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: Use Cases for Connectionless Push support in Webapps recharter

[Ian Hickson]

On Fri, 13 Jan 2012, Arthur Barstow wrote:
>
> Hixie - what are your thoughts on these UCs and how they would be 
> spec'ed? For example, would they be in a different spec, an L.next type 
> spec?

Well there's two parts to it: the protocol, and the API. If there's an 
existing protocol for this and the browser vendors are interested in 
implementing it, I see no reason why we couldn't support this alongside 
the current text/event-stream-based API in the HTML standard, either as 
part of the same API or as a separate API (like WebSockets).

If it needs a new protocol, then that should probably be addressed first.

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: File modification

[Glenn Maynard]

That would be bad; it would require null checks that people would forget to
perform due to the rarity of the condition.  Instead, it should return a
File that fails when read attempts are made.  (Of course, those errors are
also rare, but it's at least not adding a *new* rare case.)
On Jan 13, 2012 12:13 PM, "Arun Ranganathan" 
wrote:

> On 1/12/12 12:53 PM, Arun Ranganathan wrote:
>
> Oh I'm glad to see this one! Is it Blob and File that can be put into IDB?
> How do I create a new File (with a name field) from a Blob?
> Charles: see the thread on making Blobs constructable -- follow
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html
>
>
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html
>
> Seems like the consensus was to stay away from Blob to File methods.
> FileEntry and [a download] being the heirs apparent.
>
>
> Well, the consensus was to introduce a constructor to Blob, which I'm
> about to do :)
>
>
>  The File API specification should do a better job describing what
> happens to a File if the underlying resource changes.  We use the word
> immutable, but I think we have to make this substantially clearer.
>
>
> My take on a File object that's been modified is that the file no longer
> exists.
> "User agents MUST process reads on files that no longer exist at the time
> of read as errors"
> "A file may change on disk since the original file selection, thus
> resulting in an invalid read."
>
>
> Just to be clear, "disappearing" a file from FileList might is the same as
>
> item(index)
>
> returning null for the the index'th item.  Maybe this should be enforced
> as well for any kind of modification?  This isn't what Fx does today.
>
> -- A*
>

Re: File modification

[Charles Pritchard]

On 1/13/12 11:13 AM, Arun Ranganathan wrote:

On 1/12/12 12:53 PM, Arun Ranganathan wrote:

Oh I'm glad to see this one! Is it Blob and File that can be
put into IDB? How do I create a new File (with a name field)
from a Blob?
Charles: see the thread on making Blobs constructable --
follow
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html


http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html

Seems like the consensus was to stay away from Blob to File
methods. FileEntry and [a download] being the heirs apparent.


Well, the consensus was to introduce a constructor to Blob, which I'm 
about to do :)


Sorry, I misread that thread; and misremembered it. I saw it as 
appending multiple strings.

I'm happy to see the Blob constructor happening!



The File API specification should do a better job describing
what happens to a File if the underlying resource changes.  We
use the word immutable, but I think we have to make this
substantially clearer.


My take on a File object that's been modified is that the file no
longer exists.
"User agents MUST process reads on files that no longer exist at
the time of read as errors"
"A file may change on disk since the original file selection, thus
resulting in an invalid read."


Just to be clear, "disappearing" a file from FileList might is the 
same as|


item(index)

|returning null for the the index'th item.  Maybe this should be 
enforced as well for any kind of modification?  This isn't what Fx 
does today.


I'm fine with that being the defined behavior for FileList when 
implementations have elected to remove modified files.
It's still optional: implementations MAY remove modified files from the 
FileList, those that do MUST return null for the index'th item.


I'm hoping they don't go down that route. It may mean a disconnect 
between the results of submitting a post

and the files available to the scripting environment.

Again, I don't imagine that  and a subsequent 
.submit() would result in an empty POST when the user modifies the 
underlying file.
Though it should do so if the user deletes or renames the underlying 
file. I suppose things could get nasty, though, if the user modifies the 
file while the post is happening. I don't want to think about those kind 
of race conditions. Hopefully the UA can put a temporary write lock on 
those files.


Well... I'm satisfied on this topic. I think we've incrementally 
improved what the File API will specify.


-Charles

Re: Selection of a document that doesn't have a window

[Ojan Vafai]

On Fri, Jan 13, 2012 at 10:55 AM, Boris Zbarsky  wrote:

> On 1/13/12 1:28 PM, Aryeh Gregor wrote:
>
>> On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky  wrote:
>>
>>> I would prefer a definition that doesn't involve defaultView, actually.
>>>  I
>>> don't expect browsers to converge defaultView behavior any time in the
>>> near
>>> or medium future, so the testability would be illusory: tests would just
>>> depend on whether browsers implement defaultView "correctly"...
>>>
>>
>> What well-defined alternative do you suggest?
>>
>
> I'm not sure.  There's basically zero browser compat here in the hard
> cases


We could define it in terms of defaultView (or browsing context) and put
our effort into getting interoperability on defaultView?

[indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

Given the changes that Jonas made to the spec, on which other scenarios do we 
expect developers to specify a keyPath with an empty string (i.e. keyPath = 
"")?  Do we still need to support this or can we just throw if this takes 
place.  I reopened bug #14985 [1] to reflect this.  Jonas or anyone else could 
you please clarify?

Israel
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985

Re: Selection of a document that doesn't have a window

[Aryeh Gregor]

On Thu, Jan 12, 2012 at 3:07 PM, Ojan Vafai  wrote:
> Can you do anything useful with a selection on a document that doesn't have
> a window? If so, the IE9 behavior makes sense. If not, I prefer the WebKit
> behavior.

Per spec, you can add any Range at all to a Selection, so you can
programmatically manipulate it just fine.  However, the Selection of a
document without a window wouldn't have any user-visible function, so
WebKit's behavior probably does make the most sense.

Does anyone object to WebKit's behavior -- i.e.,
Document.prototype.getSelection() returning null if there's no
associated Window (however that's defined)?

> For phrasing it, could you define it in terms of document.defaultView? In
> other words that document.getSelection is just "return document.defaultView
> ? document.defaultView.getSelection() : null".

That's actually how I used to define it until just now, when I
revamped the details of Selection to better match reality in other
ways.

On Thu, Jan 12, 2012 at 1:20 PM, Boris Zbarsky  wrote:
> In Gecko, this is arguably an implementation bug.  It returns the selection
> associated with a particular Window object.  Which Window that is depends on
> how the document was created; I don't know that there's any such concept in
> the spec.

After consulting with #whatwg, I had previously defined it as the
window that contained the interface prototype object for the document.
 I.e., such that w.Document.prototype == Object.getPrototypeOf(doc).
But this might not be useful.  Returning null probably makes more
sense.

On Fri, Jan 13, 2012 at 2:37 AM, Simon Pieters  wrote:
> HTML uses this concept in lots of places, e.g.
> http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object
>
> "A Document that has no browsing context."

That's what Hixie suggested, but that's not actually defined anywhere, is it?

On Fri, Jan 13, 2012 at 11:12 AM, Boris Zbarsky  wrote:
> Ah, that's better than using defaultView (because behavior for defaultView
> on navigation and such is not defined in the spec and is not consistent
> across browsers).

Actually, defaultView is defined to return the Document's browsing
context's WindowProxy object, if it has one, and null otherwise.  Thus
per spec, defaultView returns null if and only if the document has no
browsing context.  The concept doesn't seem well-defined anywhere I
can find.  I filed a bug against HTML:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15548

For now I'm inclined to go with defaultView being null, just because
that's at least readily testable.  If defaultView isn't defined well
enough, that should be fixed in the HTML spec.

Re: Selection of a document that doesn't have a window

[Boris Zbarsky]

On 1/13/12 1:28 PM, Aryeh Gregor wrote:

On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky  wrote:

I would prefer a definition that doesn't involve defaultView, actually.  I
don't expect browsers to converge defaultView behavior any time in the near
or medium future, so the testability would be illusory: tests would just
depend on whether browsers implement defaultView "correctly"...


What well-defined alternative do you suggest?


I'm not sure.  There's basically zero browser compat here in the hard 
cases


-Boris

Re: Selection of a document that doesn't have a window

[Aryeh Gregor]

On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky  wrote:
> I would prefer a definition that doesn't involve defaultView, actually.  I
> don't expect browsers to converge defaultView behavior any time in the near
> or medium future, so the testability would be illusory: tests would just
> depend on whether browsers implement defaultView "correctly"...

What well-defined alternative do you suggest?  "Is the .document of
some Window"?  That would be easy enough to test in simple cases, but
what if there's navigation and a reference to the Document is kept but
the Window is no longer accessible, or something like that?

RE: to add Speech API to Charter; deadline January 19

[Deborah Dahl]

How prioritization works in practice depends on how a specific Working Group
decides to organize its work, but generally, the W3C is very
consensus-oriented and tries to make sure that all opinions are respected.

> -Original Message-
> From: Dave Bernard [mailto:dbern...@intellectiongroup.com]
> Sent: Friday, January 13, 2012 1:39 PM
> To: 'Deborah Dahl'; 'Satish S'; 'Young, Milan'
> Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
> Subject: RE: to add Speech API to Charter; deadline January 19
> 
> Deborah-
> 
> So how would a good "democratic" prioritization work, in practice? Is that
> something that is rare/common in similar W3C endeavors?
> 
> Dave
> 
> 
> -Original Message-
> From: Deborah Dahl [mailto:d...@conversational-technologies.com]
> Sent: Friday, January 13, 2012 12:00 PM
> To: dbern...@intellectiongroup.com; 'Satish S'; 'Young, Milan'
> Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
> Subject: RE: to add Speech API to Charter; deadline January 19
> 
> I agree that getting "good enough" out there sooner is an excellent goal,
> although in practice there's always a lot of room for disagreement about
> what's "good enough".
> There isn't a draft priority list now, although the XG final report does
> include prioritized requirements [1]. However, the requirements in the
list
> are just prioritized into very general classes, like "strong interest", so
> they only provide a general guide to possible priorities for the
> standardization work.
> 
> [1]
> http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-
> 20111206/#priorit
> ized
> 
> > -Original Message-
> > From: Dave Bernard [mailto:dbern...@intellectiongroup.com]
> > Sent: Friday, January 13, 2012 11:14 AM
> > To: 'Deborah Dahl'; 'Satish S'; 'Young, Milan'
> > Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
> > Subject: RE: to add Speech API to Charter; deadline January 19
> >
> > Deborah-
> >
> > Is there a draft priority list in existence? I like the idea of
> > getting "good enough" out there sooner, especially as an implementer
> > with real projects in the space.
> >
> > Dave
> >
> > -Original Message-
> > From: Deborah Dahl [mailto:d...@conversational-technologies.com]
> > Sent: Friday, January 13, 2012 10:43 AM
> > To: 'Satish S'; 'Young, Milan'
> > Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
> > Subject: RE: to add Speech API to Charter; deadline January 19
> >
> > Olli has a good point that it makes sense to implement the SpeechAPI
> > in pieces. That doesn't mean that the WebApps WG only has to look at
> > one proposal in deciding how to proceed with the work. Another option
> > would be to start off the Speech API work in the Web Apps group with
> > both proposals (the Google proposal and the SpeechXG report) and let
> > the editors
> prioritize
> > the order that the different aspects of the API are worked out and
> published
> > as specs.
> >
> > > -Original Message-
> > > From: Satish S [mailto:sat...@google.com]
> > > Sent: Thursday, January 12, 2012 5:01 PM
> > > To: Young, Milan
> > > Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org
> > > Subject: Re: to add Speech API to Charter; deadline January 19
> > >
> > > Milan,
> > > It looks like we fundamentally agree on several things:
> > > *  That we'd like to see the JavaScript Speech API included in the
> > > WebApps' charter.*  That we believe the wire protocol is best suited
> > > for another organization, such as IETF.*  That we believe the markup
> > > bindings may be excluded.
> > > Our only difference seems to be whether to start with the extensive
> > > Javascript API proposed in [1] or the simplified subset of it
> > > proposed in [2] which supports majority of the use cases in the XG’s
> > > Final Report.
> > >
> > > Art Barstow asked for “a relatively specific proposal” and provided
> > > some precedence examples regarding the level of detail. [3] Olli
> > > Pettay wrote in [4] “Since from practical point of view the
> > > API+protocol XG defined is a huge thing to implement at once, it
> > > API+makes
> > > sense to implement it in pieces.”
> > > Starting with a baseline that supports the majority of use cases
> > > will accelerate implementation, interoperability testing,
> > > standardization and ultimately developer adoption.
> > > Cheers
> > > Satish
> > >
> > > [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-
> htmlspeech/[2]
> > > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-
> > > 1696/speechapi.html[3]
> > > http://lists.w3.org/Archives/Public/public-
> > > webapps/2011OctDec/1474.html[4]
> > > http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.h
> > > tm l On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan
> > > 
> > > wrote:
> > > >
> > > > I've made the point a few times now, and would appreciate a
response.
> > > > Why are we preferring to seed WebApps speech with [2] when 

Re: File modification

[Arun Ranganathan]

On 1/12/12 12:53 PM, Arun Ranganathan wrote: 
> > Oh I'm glad to see this one! Is it Blob and File that can be put
> > into
> > IDB? How do I create a new File (with a name field) from a Blob?
> 
> > Charles: see the thread on making Blobs constructable -- follow
> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html
> 

> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html

> Seems like the consensus was to stay away from Blob to File methods.
> FileEntry and [a download] being the heirs apparent.

Well, the consensus was to introduce a constructor to Blob, which I'm about to 
do :) 

> > The File API specification should do a better job describing what
> > happens to a File if the underlying resource changes. We use the
> > word immutable, but I think we have to make this substantially
> > clearer.
> 

> My take on a File object that's been modified is that the file no
> longer exists.
> "User agents MUST process reads on files that no longer exist at the
> time of read as errors"
> "A file may change on disk since the original file selection, thus
> resulting in an invalid read."

Just to be clear, "disappearing" a file from FileList might is the same as 

item(index) 

returning null for the the index'th item. Maybe this should be enforced as well 
for any kind of modification? This isn't what Fx does today. 

-- A* 

Re: Selection of a document that doesn't have a window

[Boris Zbarsky]

On 1/13/12 12:18 PM, Aryeh Gregor wrote:

Actually, defaultView is defined to return the Document's browsing
context's WindowProxy object, if it has one, and null otherwise.


Hmm.  I guess the spec doesn't really define what happens to the 
association between a document and its browsing context in the 
interesting cases (window close, navigation away from document, removal 
of an iframe from the DOM, etc).  In practice, UAs are all over the map 
in terms of nulling out defaultView for some but not others of the above.



For now I'm inclined to go with defaultView being null, just because
that's at least readily testable.  If defaultView isn't defined well
enough, that should be fixed in the HTML spec.


I would prefer a definition that doesn't involve defaultView, actually. 
 I don't expect browsers to converge defaultView behavior any time in 
the near or medium future, so the testability would be illusory: tests 
would just depend on whether browsers implement defaultView "correctly"...


-Boris

RE: to add Speech API to Charter; deadline January 19

[Deborah Dahl]

I agree that getting "good enough" out there sooner is an excellent goal,
although in practice there's always a lot of room for disagreement about
what's "good enough".
There isn't a draft priority list now, although the XG final report does
include prioritized requirements [1]. However, the requirements in the list
are just prioritized into very general classes, like "strong interest", so
they only provide a general guide to possible priorities for the
standardization work.

[1]
http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#priorit
ized

> -Original Message-
> From: Dave Bernard [mailto:dbern...@intellectiongroup.com]
> Sent: Friday, January 13, 2012 11:14 AM
> To: 'Deborah Dahl'; 'Satish S'; 'Young, Milan'
> Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
> Subject: RE: to add Speech API to Charter; deadline January 19
> 
> Deborah-
> 
> Is there a draft priority list in existence? I like the idea of getting
> "good enough" out there sooner, especially as an implementer with real
> projects in the space.
> 
> Dave
> 
> -Original Message-
> From: Deborah Dahl [mailto:d...@conversational-technologies.com]
> Sent: Friday, January 13, 2012 10:43 AM
> To: 'Satish S'; 'Young, Milan'
> Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
> Subject: RE: to add Speech API to Charter; deadline January 19
> 
> Olli has a good point that it makes sense to implement the SpeechAPI in
> pieces. That doesn't mean that the WebApps WG only has to look at one
> proposal in deciding how to proceed with the work. Another option would be
> to start off the Speech API work in the Web Apps group with both proposals
> (the Google proposal and the SpeechXG report) and let the editors
prioritize
> the order that the different aspects of the API are worked out and
published
> as specs.
> 
> > -Original Message-
> > From: Satish S [mailto:sat...@google.com]
> > Sent: Thursday, January 12, 2012 5:01 PM
> > To: Young, Milan
> > Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org
> > Subject: Re: to add Speech API to Charter; deadline January 19
> >
> > Milan,
> > It looks like we fundamentally agree on several things:
> > *  That we'd like to see the JavaScript Speech API included in the
> > WebApps' charter.*  That we believe the wire protocol is best suited
> > for another organization, such as IETF.*  That we believe the markup
> > bindings may be excluded.
> > Our only difference seems to be whether to start with the extensive
> > Javascript API proposed in [1] or the simplified subset of it proposed
> > in [2] which supports majority of the use cases in the XG’s Final
> > Report.
> >
> > Art Barstow asked for “a relatively specific proposal” and provided
> > some precedence examples regarding the level of detail. [3] Olli
> > Pettay wrote in [4] “Since from practical point of view the
> > API+protocol XG defined is a huge thing to implement at once, it makes
> > sense to implement it in pieces.”
> > Starting with a baseline that supports the majority of use cases will
> > accelerate implementation, interoperability testing, standardization
> > and ultimately developer adoption.
> > Cheers
> > Satish
> >
> > [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2]
> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-
> > 1696/speechapi.html[3]
> > http://lists.w3.org/Archives/Public/public-
> > webapps/2011OctDec/1474.html[4]
> > http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.htm
> > l On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan
> > 
> > wrote:
> > >
> > > I've made the point a few times now, and would appreciate a response.
> > > Why are we preferring to seed WebApps speech with [2] when we
> > > already have [3] that represents industry consensus as of a month
> > > ago (Google not withstanding)?  Proceeding with [2] would almost
> > > surely delay the resulting specification as functionality would
> > > patched and haggled over to meet consensus.
> > >
> > > My counter proposal is to open the HTML/speech marriage in WebApps
> > > essentially where we left off at [3].  The only variants being: 1)
> > > Dropping the markup bindings in sections 7.1.2/7.1.3 because its
> > > primary supporter has since expressed non-interest, and 2) Spin the
> > > protocol specification in 7.2 out to the IETF.  If I need to
> > > formalize all of this in a document, please let me know.
> > >
> > > Thank you
> > >
> > > [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
> > >
> > >
> > >
> > > -Original Message-
> > > From: Arthur Barstow [mailto:art.bars...@nokia.com]
> > > Sent: Thursday, January 12, 2012 4:31 AM
> > > To: public-webapps
> > > Cc: public-xg-htmlspe...@w3.org
> > > Subject: CfC: to add Speech API to Charter; deadline January 19
> > >
> > > Glen Shires and some others at Google proposed [1] that WebApps add
> > > Speech API to WebApps' charter and they put forward the Spe

Re: Selection of a document that doesn't have a window

[Boris Zbarsky]

On 1/13/12 2:37 AM, Simon Pieters wrote:

HTML uses this concept in lots of places, e.g.
http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object

"A Document that has no browsing context."


Ah, that's better than using defaultView (because behavior for 
defaultView on navigation and such is not defined in the spec and is not 
consistent across browsers).


-Boris

RE: to add Speech API to Charter; deadline January 19

[Young, Milan]

That's exactly the right question to ask.  Please take a look at: 
http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#requirements

I am also in support of Olli's statement that we may not be able to 
spec/implement the complete XG recommendation in one pass.  But decisions made 
toward the definition of that initial feature set should be made in a 
democratic forum.  I feel the best way to do that is to start where the last 
democratic forum left off, and whittle down from there as schedule requires.

Thank you


-Original Message-
From: Dave Bernard [mailto:dbern...@intellectiongroup.com] 
Sent: Friday, January 13, 2012 8:14 AM
To: 'Deborah Dahl'; 'Satish S'; Young, Milan
Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
Subject: RE: to add Speech API to Charter; deadline January 19

Deborah-

Is there a draft priority list in existence? I like the idea of getting "good 
enough" out there sooner, especially as an implementer with real projects in 
the space.

Dave

-Original Message-
From: Deborah Dahl [mailto:d...@conversational-technologies.com]
Sent: Friday, January 13, 2012 10:43 AM
To: 'Satish S'; 'Young, Milan'
Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org
Subject: RE: to add Speech API to Charter; deadline January 19

Olli has a good point that it makes sense to implement the SpeechAPI in pieces. 
That doesn't mean that the WebApps WG only has to look at one proposal in 
deciding how to proceed with the work. Another option would be to start off the 
Speech API work in the Web Apps group with both proposals (the Google proposal 
and the SpeechXG report) and let the editors prioritize the order that the 
different aspects of the API are worked out and published as specs.

> -Original Message-
> From: Satish S [mailto:sat...@google.com]
> Sent: Thursday, January 12, 2012 5:01 PM
> To: Young, Milan
> Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org
> Subject: Re: to add Speech API to Charter; deadline January 19
> 
> Milan,
> It looks like we fundamentally agree on several things:
> *  That we'd like to see the JavaScript Speech API included in the 
> WebApps' charter.*  That we believe the wire protocol is best suited 
> for another organization, such as IETF.*  That we believe the markup 
> bindings may be excluded.
> Our only difference seems to be whether to start with the extensive 
> Javascript API proposed in [1] or the simplified subset of it proposed 
> in [2] which supports majority of the use cases in the XG's Final 
> Report.
> 
> Art Barstow asked for "a relatively specific proposal" and provided 
> some precedence examples regarding the level of detail. [3] Olli 
> Pettay wrote in [4] "Since from practical point of view the
> API+protocol XG defined is a huge thing to implement at once, it makes
> sense to implement it in pieces."
> Starting with a baseline that supports the majority of use cases will 
> accelerate implementation, interoperability testing, standardization 
> and ultimately developer adoption.
> Cheers
> Satish
> 
> [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-
> 1696/speechapi.html[3]
> http://lists.w3.org/Archives/Public/public-
> webapps/2011OctDec/1474.html[4]
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.htm
> l On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan 
> 
> wrote:
> >
> > I've made the point a few times now, and would appreciate a response.
> > Why are we preferring to seed WebApps speech with [2] when we 
> > already have [3] that represents industry consensus as of a month 
> > ago (Google not withstanding)?  Proceeding with [2] would almost 
> > surely delay the resulting specification as functionality would 
> > patched and haggled over to meet consensus.
> >
> > My counter proposal is to open the HTML/speech marriage in WebApps 
> > essentially where we left off at [3].  The only variants being: 1) 
> > Dropping the markup bindings in sections 7.1.2/7.1.3 because its 
> > primary supporter has since expressed non-interest, and 2) Spin the 
> > protocol specification in 7.2 out to the IETF.  If I need to 
> > formalize all of this in a document, please let me know.
> >
> > Thank you
> >
> > [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
> >
> >
> >
> > -Original Message-
> > From: Arthur Barstow [mailto:art.bars...@nokia.com]
> > Sent: Thursday, January 12, 2012 4:31 AM
> > To: public-webapps
> > Cc: public-xg-htmlspe...@w3.org
> > Subject: CfC: to add Speech API to Charter; deadline January 19
> >
> > Glen Shires and some others at Google proposed [1] that WebApps add 
> > Speech API to WebApps' charter and they put forward the Speech 
> > Javascript API Specification [2] as as a starting point. Members of 
> > Mozilla and Nuance have voiced various levels of support for this 
> > proposal. As such, this is a Call for Consen

RE: to add Speech API to Charter; deadline January 19

[Deborah Dahl]

Olli has a good point that it makes sense to implement the SpeechAPI in
pieces. That doesn't mean that the WebApps WG only has to look at one
proposal in deciding how to proceed with the work. Another option would be
to start off the Speech API work in the Web Apps group with both proposals
(the Google proposal and the SpeechXG report) and let the editors prioritize
the order that the different aspects of the API are worked out and published
as specs.

> -Original Message-
> From: Satish S [mailto:sat...@google.com]
> Sent: Thursday, January 12, 2012 5:01 PM
> To: Young, Milan
> Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org
> Subject: Re: to add Speech API to Charter; deadline January 19
> 
> Milan,
> It looks like we fundamentally agree on several things:
> *  That we'd like to see the JavaScript Speech API included in the
> WebApps' charter.*  That we believe the wire protocol is best suited
> for another organization, such as IETF.*  That we believe the markup
> bindings may be excluded.
> Our only difference seems to be whether to start with the extensive
> Javascript API proposed in [1] or the simplified subset of it proposed
> in [2] which supports majority of the use cases in the XG’s Final
> Report.
> 
> Art Barstow asked for “a relatively specific proposal” and provided
> some precedence examples regarding the level of detail. [3]
> Olli Pettay wrote in [4] “Since from practical point of view the
> API+protocol XG defined is a huge thing to implement at once, it makes
> sense to implement it in pieces.”
> Starting with a baseline that supports the majority of use cases will
> accelerate implementation, interoperability testing, standardization
> and ultimately developer adoption.
> Cheers
> Satish
> 
> [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-
> 1696/speechapi.html[3]
> http://lists.w3.org/Archives/Public/public-
> webapps/2011OctDec/1474.html[4]
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.html
> On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan 
> wrote:
> >
> > I've made the point a few times now, and would appreciate a response.
> > Why are we preferring to seed WebApps speech with [2] when we already
> > have [3] that represents industry consensus as of a month ago (Google
> > not withstanding)?  Proceeding with [2] would almost surely delay the
> > resulting specification as functionality would patched and haggled over
> > to meet consensus.
> >
> > My counter proposal is to open the HTML/speech marriage in WebApps
> > essentially where we left off at [3].  The only variants being: 1)
> > Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary
> > supporter has since expressed non-interest, and 2) Spin the protocol
> > specification in 7.2 out to the IETF.  If I need to formalize all of
> > this in a document, please let me know.
> >
> > Thank you
> >
> > [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
> >
> >
> >
> > -Original Message-
> > From: Arthur Barstow [mailto:art.bars...@nokia.com]
> > Sent: Thursday, January 12, 2012 4:31 AM
> > To: public-webapps
> > Cc: public-xg-htmlspe...@w3.org
> > Subject: CfC: to add Speech API to Charter; deadline January 19
> >
> > Glen Shires and some others at Google proposed [1] that WebApps add
> > Speech API to WebApps' charter and they put forward the Speech
> > Javascript API Specification [2] as as a starting point. Members of
> > Mozilla and Nuance have voiced various levels of support for this
> > proposal. As such, this is a Call for Consensus to add Speech API to
> > WebApps' charter.
> >
> > Positive response to this CfC is preferred and encouraged and silence
> > will be considered as agreeing with the proposal. The deadline for
> > comments is January 19 and all comments should be sent to public-
> webapps
> > at w3.org.
> >
> > -AB
> >
> > [1]
> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
> > [2]
> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-
> 1696/s
> > peechapi.html
> >
> >

Re: Use Cases for Connectionless Push support in Webapps recharter

[Arthur Barstow]

Hi All,

With respect to the charter, the SSE snippet currently says:

[[
Server-Sent Events - An API for opening an HTTP connection for receiving 
push notifications from a server in the form of DOM events. The API is 
designed such that it can be extended to work with other push 
notification schemes such as Push SMS.

]]

Is the above sufficient to cover the UCs Bryan proposes? If not, what 
specific change(s) is needed?


Hixie - what are your thoughts on these UCs and how they would be 
spec'ed? For example, would they be in a different spec, an L.next type 
spec?


(FYI, the minutes from November 1 discussion [that I did not attend] are 
).


-AB

On 1/3/12 6:51 PM, ext Bryan Sullivan wrote:

I had an action item to provide some use cases for the Webapps
recharter process, related to the "Push based on extending server-sent
events" topic at the last F2F (draft API proposal that was presented:
http://bkaj.net/w3c/eventsource-push.html).

The intent of the action item was to establish a basis for a Webapps
charter item related to extending eventsource (or coming up with a new
API) for the ability to deliver arbitrary notifications/data to
webapps via connectionless bearers, as informationally described in
Server-Sent Events (http://dev.w3.org/html5/eventsource/).

Here are three use cases:

1)  One of Bob’s most-used apps is a social networking webapp which
enables him to remain near-realtime connected to his friends and
colleagues. During his busy social hours, when he’s out clubbing, his
phone stays pretty much connected full time, with a constant stream of
friend updates. He likes to remain just as connected though during
less-busy times, for example during the workday as friends post their
lunch plans or other updates randomly. While he wants his favorite app
to remain ready to alert him, he doesn’t want the app to drain his
battery just to remain connected during low-update periods.

2)  Alice is a collector, and is continually watching or bidding in
various online auctions. When auctions are about to close, she knows
the activity can be fast and furious and is usually watching her
auction webapp closely. But in the long slow hours between auction
closings, she still likes for her webapp to alert her about bids and
other auction updates as they happen, without delay. She needs for her
auction webapp to enable her to continually watch multiple auctions
without fear that its data usage during the slow periods will
adversely impact her profits.

3)  Bob uses a web based real-time communications service and he wants
to be available to his friends and family even when his application is
not running. Bob travels frequently and it is critical for him to
optimize data usage and preserve battery. Bob’s friends can call him
up to chat using video/audio or just text and he wants to make sure
they can reach him irrespective of what device and what network he is
connected at any given time.

Comments/questions?