[Twisted-Python] XWT

Mukhsein Johari arashi1 at pd.jaring.my
Thu May 9 09:03:21 EDT 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