- From: Richard's Hotmail <maher_rj@hotmail.com>
- Date: Sat, 27 Sep 2008 10:27:26 +0800
Hi David,
Sorry, forgot to mention a UDP Socket "push" technology demo, that I'd also
like to be able to achieve with WebSockets rather than Java Applet Sockets.
Please explain how the functionality employed in the following code could
ever be achieved with the proposed WebSockets: -
Tier3Pager.java
===========
/**
* Copyight Tier3 Software. All rights reserved.
*
* Author: Richard Maher
*
**/
import java.applet.Applet;
import java.awt.*;
import java.net.*;
import java.io.IOException;
import netscape.javascript.JSObject;
import netscape.javascript.JSException;
public class Tier3Pager extends Applet
{
private String hostName;
private JSObject browser;
private static MessageThread socketThread;
private static Tier3Talk chat;
public class MessageThread extends Thread
{
private DatagramSocket socket;
private DatagramPacket packet;
private String threadData;
public MessageThread(String name, String txt) throws Exception
{
super(name);
byte[] buffer;
threadData = txt;
String port = getParameter("PORT");
String maxBuf = getParameter("MAXBUF");
try
{
if (port == null)
socket = new DatagramSocket();
else
socket = new DatagramSocket(Integer.parseInt(port));
if (maxBuf == null)
buffer = new byte[512];
else
buffer = new byte[Integer.parseInt(maxBuf)];
packet = new DatagramPacket(buffer, buffer.length);
}
catch (Exception e)
{
e.printStackTrace();
System.out.println("Unable to create UDP Socket");
throw new Exception("Message thread could not be created");
}
setDaemon(true);
start();
}
public void shutdown()
{
socket.close();
}
public int getLocalPort()
{
return socket.getLocalPort();
}
public void run()
{
System.out.println("Started Message thread. ThreadData = " +
threadData);
String args[] = {"Started Message Thread " + threadData};
browser.call("alert", args);
boolean stopThread = false;
readLoop:
while (!stopThread)
{
try
{
socket.receive(packet);
String received = new String(packet.getData(), 0,
packet.getLength());
processMessage(received);
}
catch (SocketException e)
{
System.out.println("Shutting up shop");
stopThread = true;
continue readLoop;
}
catch (IOException e)
{
e.printStackTrace();
System.out.println("Unable to retrieve UDP message");
}
}
System.out.println("Thread run() unit terminating");
}
public void processMessage(String msgText)
{
int msgType = Integer.parseInt(msgText.substring(0,2));
switch (msgType){
case 1:
chat.append(msgText.substring(2));
break;
case 2:
String args[] = {msgText.substring(2)};
try {browser.call("priceUpdate", args);}
catch (JSException e)
{
System.out.println("Error when calling JS
priceUpdate()");
}
break;
default:
System.out.println("Unknown rec type
"+msgText);
}
}
}
public void init()
{
System.out.println("Initializing. . .");
hostName = getCodeBase().getHost();
chat = new Tier3Talk("Tier3 Messages");
requestFocus();
browser = JSObject.getWindow(this);
if (socketThread == null)
{
try
{
socketThread = new MessageThread("MsgDaemon", "SomeData");
}
catch (Exception e)
{
e.printStackTrace();
System.out.println("Could not init Tier3Pager");
}
}
}
public void alert(String alertText)
{
String args[] = {alertText};
browser.call("alert", args);
}
public void destroy()
{
if (chat != null)
chat.dispose();
boolean stillDying;
if (socketThread != null){
socketThread.shutdown();
do
{
stillDying = false;
System.out.println("Joining MessageThread");
try {socketThread.join();}
catch (InterruptedException e){
System.out.println("Interrupted Join");
stillDying = true;
}
} while (stillDying);
socketThread = null;
}
System.out.println("Tier3Pager Applet Rundown complete");
super.destroy();
}
}
Tier3Talk.java
===========
/**
* Copyright Tier3 Software. All rights reserved.
*
* Author: Richard Maher
*
**/
import java.awt.*;
import java.awt.event.*;
public class Tier3Talk extends Frame
implements WindowStateListener
{
TextArea chatPanel = new TextArea("Server messages will appear
below: -", 10, 50);
Toolkit toolkit = Toolkit.getDefaultToolkit();
boolean windowDown = true;
public Tier3Talk(String heading)
{
super(heading);
setBackground(Color.gray);
chatPanel.setEditable(false);
Panel panel = new Panel();
panel.setLayout(new FlowLayout(FlowLayout.CENTER));
panel.add(chatPanel);
add("Center", panel);
Dimension screenDim = toolkit.getScreenSize();
pack();
Dimension windowDim = getSize();
setLocation((screenDim.width - windowDim.width),(screenDim.height -
windowDim.height));
setResizable(false);
addWindowStateListener(this);
setExtendedState(Frame.ICONIFIED);
setVisible(true);
}
public void append(String newMsg)
{
chatPanel.append("\n" + newMsg);
if (windowDown)
setExtendedState(Frame.NORMAL);
toolkit.beep();
}
public void windowStateChanged(WindowEvent we)
{
switch (we.getNewState())
{
case Frame.ICONIFIED:
windowDown = true;
break;
case Frame.NORMAL:
windowDown = false;
break;
default:
System.out.println("Event of no interest" +
we.getNewState());
}
}
}
Cheers Richard Maher
----- Original Message -----
From: "ddailey" <ddailey@zoominternet.net>
To: "Richard's Hotmail" <maher_rj at hotmail.com>; <whatwg at whatwg.org>
Sent: Sunday, September 21, 2008 10:33 PM
Subject: Re: [whatwg] WebSocket support in HTML5
> Hi Richard,
>
> My apologies for getting involved in a topic I confess to knowing very
> little about (though I would like to be able to have direct
client-to-client
> communication for a variety of purposes including gaming and social
> networking), but it seems like the question here is "what does the
approach
> you are advocating enable that the approach on the table doesn't do?" I
> understand that you are saying the approach WHATWG and HTML5 WG have
> undertaken is flawed (and I acknowledge your claim that lots of folks are
> doing it better), but I really don't see what you are hoping to do that
> these folks (whose expertise in such matters I would certainly be willing
to
> defer to) will not enable? Are you claiming, for example, that HTTP
> roundtrips from a server to each client will be intrinsically too slow to
> support such applications as gaming? If so, then it would seem that would
be
> a concrete complaint that the advocates of the current proposal could, in
> theory, respond to. The history of the discussion referred to by the link,
> indicates that as James says, the current proposal has undergone numerous
> revisions based on input. Perhaps since you obviously care so much about
it,
> you can help the proposal to evolve into something which addresses your
> concerns.
>
> Just the observation of a naive onlooker.
>
> cheers
> David
>
>
>
> ----- Original Message -----
> From: "Richard's Hotmail" <maher_rj at hotmail.com>
> To: <whatwg at whatwg.org>
> Sent: Sunday, September 21, 2008 9:58 AM
> Subject: Re: [whatwg] WebSocket support in HTML5
>
>
> > 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 at 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 Friday, 26 September 2008 19:27:26 UTC