Re: Web Sockets API, buffer handling after the connection is closed

On Thu, 18 Feb 2010, Olli Pettay wrote: > > I wonder why send() needs to buffer anything after the connection is > closed. bufferedAmount is defined: "If the connection is closed, this > attribute's value will only increase with each call to the send() method > (the number does not reset to zer

Re: [widgets] API - openURL security considerations

On Thu, 18 Feb 2010 22:09:00 +0100, Scott Wilson wrote: Hi both, Apache Wookie (incubating) currently implements the widget.openURL method by directly calling the browser's window.open() function - in this example is there anything particularly special about the fact its being called by a wi

Re: Web Sockets API, buffer handling after the connection is closed

Throwing will likely lead to sites breaking since it's likely that many will not expect connections to get broken due to network issues. Having bufferedAmount continuously increase seem to address the example code you included. Or more generally, code that does: if (socket.bufferedAmount < X) s

Re: [WebTiming] HTMLElement timing

On Wed, Feb 17, 2010 at 10:36 PM, James Robinson wrote: > * What precisely does 'parse' time mean for each element?  For example, on a >

Re: [widgets] API - openURL security considerations

Hi both, Apache Wookie (incubating) currently implements the widget.openURL method by directly calling the browser's window.open() function - in this example is there anything particularly special about the fact its being called by a widget? Should our implementation do anything extra, or

[widgets] Draft minutes from 18 February 2010 voice conf

The draft minutes from the February 18 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/02/18-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before February 25 (the n

[IndexedDB] Lots of small nits and clarifying questions

I'm sorry that I let so much IndexedDB feedback get backlogged. In the future, I'll try to trickle things out slower. * * *Indexes:* 1) Creation of indexes really needs to be made more clear. For example, does creation of the index block everything until it's complete or does the database get c

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/18/2010 5:31 AM, Jeremy Orlow wrote: > On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp > wrote: > > * Use promises for async interfaces - In server side JavaScript, > most > projects are moving towards using prom

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

On Feb 18, 2010, at 4: 31AM, Jeremy Orlow wrote > Very interesting. The general concept seems promising and fairly flexible. > You can easily code in a similar style to normal async/callback semantics, > but it seems like you have a lot more flexibility. I do have a few questions > though. >

[IndexedDB] Deleting/managing databases and entity stores

Some feedback/issues based on talks with web apps teams at Google. With WebSQLDatabase, there's been some concern and headache over users being able to easily delete individual databases without fully understanding the consequences (and the fact that it might break apps in strange and unpredictab

Re: [IndexedDB] Detailed comments for the current draft

On Wed, Feb 3, 2010 at 3:37 AM, Pablo Castro wrote: > > > > I prefer to leave composite keys to a future version. > > I don't think we can get away with this. For indexes this is quite common > (if anything else to have stable ordering when the prefix of the index has > repeats). Once we have it f

[IndexedDB] Inverted indexes (for full text search)

In addition to looking at the UA side of the IndexedDB AI, I've been talking to our web apps teams about it to get their initial impressions. I'm going to batch most of the feedback together in another email, but this is a big enough feature and important enough to all of those teams that I wanted

Web Sockets API, buffer handling after the connection is closed

Hi, I wonder why send() needs to buffer anything after the connection is closed. bufferedAmount is defined: "If the connection is closed, this attribute's value will only increase with each call to the send() method (the number does not reset to zero once the connection closes)" Why not clea

[IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp wrote: > > * Use promises for async interfaces - In server side JavaScript, most > projects are moving towards using promises for asynchronous interfaces > instead of trying to define the specific callback parameters for each > interface. I believe the ad

RE: [whatwg] Window id - a proposal to leverage session usage in webapplication

[cross-posting as a similar amount of discussion has taken place on the two groups] Sebastian Hennebrueder wrote: > The browser should generate an id unique per browser window > and sent it as request header with every browser request. > Request Header > -- > X-Window-Id: 279078917624

Re: [widgets] API - openURL security considerations

Marcos, first of all, kudos for thinking about security considerations for this method. I'm glad you're considering factors like interaction flooding and tons of windows opening. Reviewing the spec text: http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-openurl-method ... I wonder wheth