Unicode, MOO, and MOOzilla
Spent the morning talking with Jason of Achieve MOO. He came over while I was at Catsy’s in Toronto. The original goal was to discuss things related to the Unicode based MOO, and we did that, as well as touching on other topics of mutual interest.
I’ll be publishing a new unicode patch shortly which allows non-us-ascii keywords and variable names in the MOO. This means that non-english words and characters can be used as variable, verb, property, and function names in MOO code without any unnecessary escaping. Collaborating with Jason showed that there are apparently duplicates of characters in the unicode codepage, such as the semicolon, period, quotation marks, and so on, which must be recognized by the MOO in the future as having the same functionality as the us-ascii versions of these characters. This should be interesting, and I’ll look into it soon for another unicode patch.
Once that was out of the way, it became apparent that the server handles Unicode great, the only problems left were in front end programs. Jason’s native OSX MUD client was able to send text to the MOO, but could not receive it and display it properly. The ‘telnet’ command in an OSX terminal was able to receive but not send, exactly the opposite. MOOzilla was able to do both. We didn’t have the resources available to easily test whether Mooca, the Achieve Java telnet client, could do it correctly and nicely.
Jason was interested in MOOzilla as a client itself. A number of ideas and problems came out of that discussion.
The idea of somehow making seperable windows out of MOOzilla which are MOO driven came up. This has been thought of before, but the way it was discussed here was as windows that could be separated, or could be left integrated in MOOzilla. This would allow a ‘power-user’ to keep everything in one complex window, while a beginning user would have a simpler interface that they could complicate if they chose to. I need to give some thought as to how this might be implemented… but I know that MOOzilla/Mozilla have the capabilities to do it.
A problem that arose is MOOzilla distribution and access. A Java client is easy to access because it requires no software installation, is just right there, and is cross-platform. MOOzilla does require software installation, two pieces of software actually, and the software varies from platform to platform. This would be streamlined a bit by the proposed ‘MOOzilla Package’ which was just MOOzilla, without Mozilla cruft, but would still not be usable in Jason’s teaching environment. So… what would? Hm… if only IE supported XUL/XPCOM. Now, if someone could make a plugin for IE that would allow the running of an XUL application… it would probably be a huge plugin. Could one be made that was MOOzilla-specific? … who knows how to make an IE plugin? Need some magic glue components here…