W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

[whatwg] WebSocket support in HTML5

From: Richard's Hotmail <maher_rj@hotmail.com>
Date: Sun, 21 Sep 2008 21:58:14 +0800
Message-ID: <BAY131-DAV2785955F67BBCF59B0E7BFB480@phx.gbl>
Hi James,

Thanks for the reply.
>
> [1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015252.html

My appologies for only having read the first ten years of that thread :-)

Look, I'm not sure exactly what problem you guys are solving with HTML5's
WebSockets but I wish you well. What I and *many* others are looking for is
native JavaScript support for Sockets  a la mode de (SUN Java Applets +
Adobe Flex + MIcrosoft Silverlight) that for some strange reason don't seem
to be subject to the same imaginary obstacles that are being discussed in
that thread. Please explain what security vulnerabilities et al that Adobe,
SUN and Microsoft have foisted upon us that the HTML5 people wish to spare
us from.

If you guys live in a world where nothing but port 80 exists and no one with
ever want UDP datagrams (let alone Multicast messages) to their web clients
then I have come to the wrong place :-(

What goes up and down the network connection is our business not yours. No
more bollocks protocols!

As I said in the previous post, if you guys want to put a "Frame me like
ASCII" contortion interface/API on top of the JavaScript Sockets (similar to
SOAP on HTTP) then go crazy; just don't try to shackle everyone else with
the same restrictions.

Please see the following for examples of what I am talking about: -

http://manson.vistech.net/t3$examples/demo_client_flex.html
http://manson.vistech.net/t3$examples/demo_client_web.html

In both cases the Username is TIER3_DEMO and the password is QUEUE.

Obviously, you can "view source" for the HTML and Javascript and the Java
Applet and MXML source can be found at
http://manson.vistech.net/t3$examples/

Once again, you are not introducing something new, but you *are* attempting
to introduce support for a tried and tested architecture and you are getting
it hopelessly wrong :-(

Cheers Richard Maher

----- Original Message ----- 
From: "James Graham" <jg307@cam.ac.uk>
To: "Richard's Hotmail" <maher_rj at hotmail.com>
Cc: <whatwg at whatwg.org>
Sent: Sunday, September 21, 2008 8:46 PM
Subject: Re: [whatwg] WebSocket support in HTML5


> Richard's Hotmail wrote:
> > Hi,
> >
> > I've been told that this is the correct forum for lobbying/venting about
> > html5 changes; I hope that this is correct?
>
> Er, I think it is the correct forum for discussing the spec. I'm less sure
that
> lobbying/venting are useful forms of discussion.
>
> > 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!
>
> Nothing is engraved into stone, at least until browsers ship something and
are
> unable to change it because it would adversely affect their marketshare.
As far
> as I am aware there are currently no browser-based implementations of
> WebSockets, so it is relatively easy to make changes.
>
> > 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.
>
> You might find [1] helpful for understanding the rationale behind the
current
> WebSockets spec. If you have use cases that cannot be met with the current
> design, it would be helpful if you could explain the use case and how you
can
> deal with the security issues identified in that email.
>
> [1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015252.html
>
> -- 
> "Eternity's a terrible thought. I mean, where's it all going to end?"
>   -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
>
Received on Sunday, 21 September 2008 06:58:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC