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