At 19:26 23.02.00 -0300, Jecel Assumpcao Jr. wrote:

I should have been more specific about what I want to do: basically the idea is to have a shared space on the internet similar to Kansas (infinite scrollable space) where the users can draw and "chat".

This is actually exactly the same type of application I wanted to create recently. We (that is www.baltic-online.de) stopped development when we noticed that our very generic approach was too slow.

I started with the assumption, that if X would be fast enough, then a specially written light-weight protocol similar to X could be fast enough to support a few (up to 10) clients over ISDN (which was our assumed minimum). I did this in Java and it worked very well with the exception that cursor movements where very sluggish and because of a high lag time, it was remotely nearly unusable.

We're now using a different approach that uses local UIs with only shared models located in a central object database.

But interestinly, drawing and chatting, actually a collaborate whiteboard was exactly our goal, too.

This is easy to program in Self (it is almost done already, after all :-) and would work fine on a high speed LAN with people using X Windows. But I see

now

that it is too ambitious to try that over a 33kbps modem.

Something that is faster than X is SLIM, the protocol used by Sun to connect SunRay1 terminals to a central server. There's a paper available online about that protocol but I didn't find an exact specifiction how to implement that protocol. They say however, it's a very simple protocol consisting of only 5 commands which are centered around bitmap copy. The paper tries to prove that SLIM is not slower than X, ofen faster and better for multi-media applications like playing movies.

At work, we've only SunRays, so I can say that it works quite well for typical business stuff like doing accounting or development. (It slows down Squeak, though, but this might be because Squeak is already slower on X than on Windows)

bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

Thanks for the input, Stefan and Jerry. I am guessing that the Sun Ray protocol is very similar to VNC, and that it also works best over fast networks.

In the end, I decided that the only way to work over the networks I will be using is to have the whole application on the client machines, including replicas of the shared model. The server would then work as a kind of hub, receiving state updates from the clients and retransmitting those to all other clients. One advantage of this design is that it can allow you to work offline as well, which is important for those with dial-up connections.

Unfortunately, I think I will be forced to use Perl for the server and Squeak for the client. Hopefully, I'll be able to replace both with Self versions before the projects ends in June.

Perl: I can run Self on the server, but my site has a 33kbps link. If the server is simple enough, then writing it in Perl will allow me to run it on any hosting provider (Rapid Site, in this case). I would much prefer Python to Perl, but many sites don't announce it being available...

Squeak: the client machines are underpowered Windows PCs. Self doesn't run on PCs yet, and when it does it will first be in Linux and it will be slow (I am supposing that the SIC won't be ported). A stripped down Squeak image can be 3MB or less, and clients don't need source and changes files. So it looks to me like a smaller download and simpler install than Java2.

Some time ago, I wrote a simulator for a chorded keyboard I designed in Self. It took me just about three minutes to get it working. I wasn't able to fully test it since the Sun keyboard doesn't allow you to press more than three keys at a time. To let other people try it (who didn't have SparcStations) I started to rewrite it in Squeak. I didn't get very far before I had to give up due to Squeak's lack of keyUp events. The I tried VisualBasic, but found that the version I had didn't generate .EXE files so I would only be able to distribute the program to those who already had VB. I considered JavaScript, but found each version of the language handled events very differently so I would have to write a special version for each browser! So I finally tried Java, using only vi and linux.jdk-1.0.2-pl1 as my development tools. Though it was my third complete rewrite of the program, this one took me much longer. The primitive tools weren't so much of a problem, but the totally misleading descriptions of the paint and update functions made we waste some two days until things were working reasonably well.

The ideal solution (not counting being able to upload "Selflets" to client machines) would be to be able to write the application in Self and have people be able to use it with their normal browsers. For a while (in 1995, I think) there was a machine at Sun outside their firewall and running Self so anyone with a X server could connect and play around. It wasn't very usable on my 14400 modem, but things are a bit faster these days.

-- Jecel