[Twisted-Python] XWT
Mukhsein Johari
arashi1 at pd.jaring.my
Thu May 9 07:03:21 MDT 2002
> I discovered XWT yesterday, and *wow*. This is very similar to something
> I've wanted to do, and it's very very cool.
I think a lot of folks have thought about "adderssing" the inability of
web-browsers to "accept" incoming messages from a server. Simply that there
isn't a particular port that a browser would listen to. This sucks as far as
p2p networking is concerned.
Currently, there are 3 approaches I know of.
One is the signed applet (as in XWT) method - this requires java (on small
devices? I doubt it) and also applet signing to enable the applet to open and
listen on a specific port.
Second is the Javascript LiveConnect - to serverside javascript method as
implemented by Netscape. I think this also involves some signing - check the
javascript docs on the net (somewhere). Incidentally, javascript<->java
applet<->server is also done via a signed java applet.
Third is the "experimental" http header mimetype: multipart/x-mixed-replace
This method is aka "server push". Konqueror has an experimental add-on called
"kmultipart" for this. Apparently, the old netscape had it. Not sure about
mozilla.
This shell script illustrates the thing - cgi-way.
#!/bin/sh
echo "HTTP/1.0 200"
echo "Content-type: multipart/x-mixed-replace;boundary=---ThisRandomString---"
echo ""
echo "---ThisRandomString---"
while true
do
echo "Content-type: text/html"
echo ""
echo "<h2>Processes on this machine updated every 5 seconds</h2>"
echo "time: "
date
echo "<p>"
echo "<plaintext>"
ps -el
echo "---ThisRandomString---"
sleep 5
done
This of course needs browser support. In fact, all of the above needs browser
support.
As you can see, it's all a lot of dirty hacks. What we really need is a
standardised, _secure_ way of doing real p2p communication between client and
server. Which really makes client and server very similar (oh ya, that's why
it's called p2p...duh). This should then be implemented by _all_ browsers. I
still find it strange that we don't have this yet...
>
> Why is this a limitation? Consider a chat application. In the XML-RPC
> model, you would need to continously poll the server for new messages - and
> if you want low latency, you need to send even more requests per second.
> This is very inefficent and puts a large load on the server.
That's why we need a better way. :-(
> What I was thinking of therefore was to use a protocol that is two-way,
> allowing the server to send commands to the client asynchronously. These
> would basically be GUI events just as you would from, say, Javascript. For
> example, in a chat application, a new message would result in the server
> sending a "add new text to message display wdiget" command being sent to
> the client, without the client having to request it.
>
> In addition for event driven client-server applications, using such a
> protocol would also allow building P2P apps that use XWT.
I don't think we want to use XWT. It'll only add yet another dependency to the
"dependency hell".
> My protocol of choice would be PB, which is a remote object protocol
> developed for the Twisted server framework
> (http://www.twistedmatrix.com/products/spread). It has implementation in
> Python, and a Java implementation I wrote
> (http://itamarst.org/software/TwistedJava-0.5.tar.gz). PB is very
> efficient, asynchronous, and two-way (for example, encoding an array
> containing a short string and two integers will take 150 bytes in XML-RPC,
> and 20 in PB). It was designed for chat systems, massive multiplayer games
> and other systems where latency must be kept at a minimum.
I think PB would be great..but what about security concerns?
Right now, you could write a signed java applet (in jython!? :-)) to do this
very thing - a PB "communicator" on the browser end. I could be wrong but I
don't think you really need XVT at all.
But then...we have the same crap thing of needing java. Have you seen how huge
the latest JRE is? It's larger than a mozilla download! I think a better
approach is to write a mozilla plugin. At least then you would have all the
important platforms covered. This plugin would be smaller, I think.
Of course...we could create our own _strict_ XML based browser in python and
wxpython or tkinter (erm...yeah) - deal with only strict xhtml so we can use
a generic xml parser. Of course then you need to think about layout and so
on...
Anyway, my 2 cents.
--
Regards,
Mukhsein Johari
More information about the Twisted-Python
mailing list