[whatwg] WebSocket support in HTML5

[Richard's Hotmail]

Hi, 

I've been told that this is the correct forum for lobbying/venting about html5 changes; I hope that this is correct?

My particular beef is with the intended WebSocket support, and specifically the restrictive nature of its implementation. I respectfully, yet forcefully, suggest that the intended implementation is complete crap and you'd do better to look at existing Socket support from SUN Java, Adobe Flex, and Microsoft Silverlight before engraving anything into stone! What we need (and is a really great idea) is native HTML/JavaScript support for Sockets - What we don't need is someone re-inventing sockets 'cos they think they can do it better.

Anyway I find it difficult to not be inflammatory so I'll stop now, but please look to the substance of my complaint (and the original post in comp.lang.JavaScript attached below) and at least question why it is that you are putting all these protocol restriction on binary socket support.

Thanks for listening. (and looking forward to UDP and Multicast support in HTML5 :-)

Cheers Richard Maher


"Richard Maher" <maher_rj at hotspamnotmail.com> wrote in message news:...
> Hi,
> 
> > Also interesting that Flex, SilverLight, and now Java are all adopting the
> > cossdomain.xml "standard". It would be nice if Microsoft introduced Socket
> > support in SilverLight but then it's so far behind Flex that it's probably
> > not an issue?
> 
> While looking for something else in Silverlight yesterday I stumbled across
> some version 2 beta documentation that says that Microsoft has in fact
> introduced native Socket support for Silverlight. Yippee! (Albeit TCP only
> at this stage.)
> 
> So I once again beseech you - if you know or can influence anybody involved
> in the HTML5 WebSocket design team, please tell them that they are getting
> it horribly, horribly wrong! Java, Flex, and now Silverlight are all giving
> us full-on unrestricted-content binary socket support and yet these
> knob-heads are tying us up in knots and doing everything they can to make it
> look/behave like HTTP. I guess that's all they know, or at least all they're
> used to :-(
> 
> Please, please, please give us complete access to the same Sockets that have
> been around for a million years and stop trying to fashion them in your
> likeness. If you're confined to talking to http servers then by all means
> stick an additional interface or abstraction on top for those who'll see fit
> to use it, but there are many of use that have no interest in being shackled
> by such nonsense.
> 
> What goes up and down the network connection is our business; not yours! NO
> MORE BOLLOCKS PROTOCOLS!
> 
> Cheers Richard Maher
> 
> "Richard Maher" <maher_rj at hotspamnotmail.com> wrote in message
> news:g9kgob$eo2$1 at news-01.bur.connect.com.au...
> > Hi Jorge,
> >
> > > But client-side Java... is it that stinky cold dying corpse ?
> >
> > That's my kind of rhetoric :-) In this case however I think you'll find
> Java
> > alive and well. (If more for infrastructure code rather than straight GUI)
> >
> > These links may also be of some interest: -
> > http://weblogs.java.net/blog/joshy/archive/2008/05/java_doodle_cro.html
> > https://jdk6.dev.java.net/plugin2/
> >
> > If you don't like Java there's always Flex. I believe Flex's Socket
> support
> > to be rudimentary at best with: -
> > . No connect Timeout
> > . No OOB support
> > . No UDP
> > but if you're already incorporating Flex into your Web apps (or AIR) then
> > why not? (Actually, in this case, I'd still use Java along side Flex and
> the
> > Adobe FABridge, but each to his own. See
> > http://manson.vistech.net/t3$examples/demo_client_flex.html for an example
> > of getting data from a Java Socket and populating a Flex DataGrid for
> > presentation in Flex charting. Once again, all source including MXML file
> > can be found at http://manson.vistech.net/t3$examples/ )
> >
> > > I'd rather wait for HTML5
> >
> > If you are refering to WebSockets with HTML5 then I obviously have to say
> > "What a great idea!". But what an absolute bollocks implementation :-( If
> > anyone has any input at all with these guys can you please ask them to go
> > back to the drawing board and work out what a socket actually is. Yes, we
> > *want* WebSockets but not some piece o' shit implementation as the God of
> > HTTP would've intended!)
> >
> > Also interesting that Flex, SilverLight, and now Java are all adopting the
> > cossdomain.xml "standard". It would be nice if Microsoft introduced Socket
> > support in SilverLight but then it's so far behind Flex that it's probably
> > not an issue?
> >
> > > and in the meantime will keep fudging with
> > > http/XHRs.
> >
> > Why not, that's what everyone else does; and fudging things what the web's
> > all about :-)
> >
> > Cheers Richard Maher
> >
> > "Jorge" <jorge at jorgechamorro.com> wrote in message
> > news:89d720a4-3abc-40a0-86da-720a94f353fd at j22g2000hsf.googlegroups.com...
> > On Sep 1, 2:03 am, "Richard Maher" <maher... at hotspamnotmail.com>
> > wrote:
> > >
> > > With a context-devoid, *stateless* , pile-of-pooh like HTTP, the options
> > > are clearly limited. (...)
> >
> > Richard, the way I see it http has proved to be quite handsome (much
> > more than enough).
> > And lots of things can be done with it just needs a little bit more
> > verbosity than usual.
> >
> > > If on the other hand you were to use a socket setup, similar to the
> > example
> > > that I posted, then the server would be notified of socket disconnection
> > and
> > > could take appropriate action to quiesce whatever it was doing. (There
> is
> > > also an example of a hot-abort button; so if a given query is taking too
> > > long, the clicking of the button will send an OOB character down the
> line.
> > > In this case the query can be cancelled, yet the connection maintained.)
> > >
> > > A copy of the Java Applet code is
> > at: - http://manson.vistech.net/t3$examples/
> >
> > But client-side Java... is it that stinky cold dying corpse ?
> > I'd rather wait for HTML5, and in the meantime will keep fudging with
> > http/XHRs.
> >
> > :-)
> >
> > Regards,
> > --
> > Jorge.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080921/c14ab8c2/attachment-0001.htm>