Subject: Re: [hybi] WebSockets feedback (Was: Bayeux / Jetty perspective.)

From: Mridul Muralidharan <[email-masked]>
Date: Tue, 7 Apr 2009 11:06:54 +0530 (IST)

Note that browser based javascript clients are not the only consumers of bi-directional http; others like mobile clients, firewalled thick clients, etc are also possible (and actually exist with BOSH for example).

So possibly targeting specific implementation technology might not be appropriate for designing the spec ?

Regards,
Mridul

PS: Not particularly responding to this message - the thread as such seemed to have a strong javascript bias - particularly for WebSockets design parts.

--- On Tue, 7/4/09, Ian Hickson <[email-masked]> wrote:

> From: Ian Hickson <[email-masked]>
> Subject: Re: [hybi] WebSockets feedback (Was: Bayeux / Jetty perspective.)
> To: "Greg Wilkins" <[email-masked]>
> Cc: [email-masked]
> Date: Tuesday, 7 April, 2009, 10:23 AM
> On Tue, 7 Apr 2009, Greg Wilkins
> wrote:
> > > 
> > > The WebSocket protocol is extensible by design.
> It supports two kinds 
> > > of frames (0xFF-sentinel-delimited and
> predeclared-length), and there 
> > > can be up to 128 subtypes of each kind. The
> current version only 
> > > exposes one of these, with a payload defined to
> be UTF-8.
> > 
> > this is extensibility by the protocol specifiers, so
> that later versions 
> > of the protocol can introduce new packets without
> breaking backwards 
> > compatibility.
> 
> Right.
> 
> 
> > But HTTP is user extensible.  So if I invent a
> new content type, 
> > encoding or compression algorithm, I don't need to
> wait for HTTP/1.2 to 
> > use that.  I don't need to apply to some
> standards body to allocate an 
> > identifier from a scarce (128) space.
> >
> > Defining subtypes for compress-utf8-data,
> gzip-utf8-data, gzip-utf8-data 
> > will use up a 128 space very quickly.
> 
> Sure, but that won't happen. The protocol has one purpose:
> to be the 
> backend for an API exposed by browsers to Web page scripts.
> Web Sockets 
> would be a terrible protocol to use for other purposes --
> just use TCP!
> 
> Since it is highly unlikely that browser vendors would be
> interested in 
> adding hundreds of different ways of encoding data, the
> protocol is 
> unlikely to need many of its frame types. We wouldn't want
> anyone to be 
> extending the protocol without updating the API; that would
> be missing 
> the point, as browsers wouldn't know how to support those
> types.
> 
> Having said that, if we do find we're running out, we can
> just define that 
> types 0x7F and 0xFF will have further information at the
> start of the 
> payload saying what the type is.
> 
> -- 
> Ian Hickson           
>    U+1047E         
>       )\._.,--.....,'``.    fL
> http://ln.hixie.ch/   
>    U+263A         
>       /,   _..
> \   _\  ;`._ ,.
> Things that are impossible just take
> longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
> 

      Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/