[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hybi] Proposed Charter for HyBi WG (rev.3)



On Thu, 29 Oct 2009, Salvatore Loreto wrote:
> 
> Since any modification of the web infrastructure may take a good amount 
> of time to be deployed, outputs of the working group will include both 
> short and long term solutions.

I think that's the wrong characterisation of the spaces that people want 
to work in. I think a better way to characterise it would be that there 
are three use cases people are interested in, with different needs:

 * Providing a standard way of doing two-way communication tunneled over 
   HTTP, for use by applications that cannot use TCP, Jabber, BEEP, or 
   other existing solutions in that space due to intermediaries, 
   firewalls, NATs, etc.

 * Providing something as close to TCP as possible to Web applications 
   (i.e. JavaScript running in HTML on Web browsers), while maintaining 
   the Web origin security model and fitting the Web development model 
   (e.g. event-based, not stream-based).

 * Providing a standard way of doing "hanging-GET" two-way communication 
   to HTTP servers along the lines of what interactive AJAX pages do.


> In particular, the working group will liaison with the W3C WebApps 
> working group around the WebSockets protocol and the requirements to 
> support the WebSocket API; if agreed by both parties, the HyBi working 
> group may take on prime responsibility on the specification of the 
> WebSockets protocol.

We should also liason with the WHATWG, since that's where most of the 
WebSockets work has happened. (The W3C Web Apps working group hasn't 
worked on the protocol at all, and they already liase with the WHATWG for 
the API.)

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

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.