Author: ["Calin"]
Language: [http://developer.mozilla.org/en/docs/Javascript Javascript]
Libraries: ["HTTPSocket"] (AJAX version), [http://www.webtoolkit.info/javascript-base64.html webtoolkit base64]
Platform: Modern web browsers
WebMuck is our latest and most successful attempt at a zero-install firewall-busting Muck client.
It's been a long road, and here's how we got here:
SimpleClient 1999(?) - 2000(?)
Author: ["Akili"]
Language: Visual_basic
Platform: Windows
The reason
- A portable muck-style telnet client, able to fit on and run from a single floppy disk.
The execution
- Akili wrote a very simple client in VB, and it seemed to meet the requirements.
The failure
- VB's runtime library was itself too large to fit on a floppy. So it only met the requirements if the library had already been installed on the target machine.
Historical Notes
- Upon determining the failure, Akili began adding features, but could never quite get colored text to work, which precluded a number of concepts.
SplitClient 2000(?) - present
Author: ["Akili"]
Language: Visual_basic
Platform: Windows
The reason
Because it didn't fit on a floppy anyway, SimpleClient began to accumulate features. All the things we'd seen and liked in other muck clients, and many things we'd wished for.
The execution
SimpleClient was renamed, and its list of required libraries grew quite a bit. It became a very nice full- featured muck client.
The failure
- We still didn't have an easily portable muck client.
Historical Notes
SplitClient was born when Akili deciphered how to bend Rtf to his will. Numerous long-delayed features were finally added. Not that all of them worked as intended.
WebNet 2000(?)
Authors: ["Akili"] and ["Calin"]
Language: Visual_basic
Platform: Windows (Though any browser could access it)
The reason
- A web-based muck client that needed no installation at all, and just used a web browser.
The execution
- Our first attempt at a cgi-ish program. It was written in VB, and used a persistent http connection to stream output text to the client, and a simple input form to submit text.
The failure
- The VB winsock control sucks, persistent http connections are very bad form, and it barely worked.
Historical Notes
- Originally created with a 3rd-party socket control, it had too many order-of-operations conflicts. One of the only programs written that would run fine for a day, mysteriously crash, and never run again until the next complete rewrite. At least three of these were performed.
ProxyClient 2001(?) - 2002(?)
Author: ["Calin"]
Language: Visual_basic
Platform: Windows
The reason
- To let users behind restrictive firewalls connect to mucks.
The execution
- VB again, Calin mostly responsible. The client would be installed on the restricted machine, and listen on local ports. When connections were made, it would open a connection via a standard web port (443) to the server, which would use a data header to determine what host:port to forward the connection to. We made good use of this for quite some time.
The failure
- The client component and a muck client needed to be installed on the client machine. Not good for those pretending to only be working. Also, data was sent in the clear. Again not good for the paranoid. Lastly, we moved our server from winnt to linux, and the server portion of the proxy no longer worked.
Mini Client 2001
Author: ["Cal"]
Language: Java
Platform: A java-enabled web browser
The reason
- Simple muck client that doesn't have to be installed on client computer
The execution
- Written by Cal largely as a learning experience in java. Later reworked by Calin to produce early Jmuck.
The failure
- Shortage of features. Some ugly quirks.
Jmuck 2003(?) - 2005
Author: ["Calin"]
Language: Java
Platform: Any Java-enabled web browser
The reason
- To create a muck client that required no software installation and generated no suspicious traffic.
The execution
- Cal wrote the ["HTTPSocket"] class in java, which functioned as a drop-in replacement for the standard socket class. HTTPSocket sent data encoded as base64 and wrapped in http headers over https to the server, where a perl cgi written by Calin would create and maintain the connection. Calin then wrote a java muck client utilizing HTTPSocket. This got the job done quite well, and was used for a goodly long time.
The failure
- The interface was ugly, and acted unpredictably on various browsers and java implementations. Microsoft was forced to abandon their own JVM, and elected not to have IE come bundled with Sun's JVM, so maintaining IE compatibility meant only using features that were fairly ancient.
Jmuck2 2004 - 2005
Author: ["Calin"]
Language: Java
Platform: Any Sun-Java-enabled web browser
The reason
- MS JVM sucks.
The execution
- Using the AWT toolkit, the user interface was MUCH nicer, and Calin was able to support fancier features such as hyperlinks.
The failure
- Only compatible with Sun Java, this now no longer meets the 'no installation' requirement. Also, as great as SunJVM is compared to MS JVM, it is still clunky and unpredictable on various disparate browsers and operating systems.
And finally...
WebMuck 9/2005 to Present
Author: ["Calin"]
Language: [http://developer.mozilla.org/en/docs/Javascript Javascript]
Libraries: ["HTTPSocket"] (AJAX version), [http://www.webtoolkit.info/javascript-base64.html webtoolkit base64]
Platform: Modern web browsers
The reason
- Remove cross-platform oddities. Meet the no-installation requirement.
The execution
- Written completely in cross-browser javascript, html, and css.
No failure yet!
- Prototyping and writing was amazingly fast and easy.