Plans, Schemes Made For New Server Software

Fuzzball, the basic server software on which SpinDizzy and many other mucks run, has had no updates in more than two years. GlowMuck and Protomuck, other database software, have gone similarly long whiles without exiting “maintenance mode.”  The principles of the servers, their management, and their operations were laid down and remain fundamentally unaltered from the earliest days of the publicly-popular Internet. The question of whether it is time to build a new muck server code base was discussed in an OOC meeting on the 27th of March, in the Center of Arts and Science Classroom.

The discussion, begun by Morticon’s player — who has been looking at some of the more antique elements of Fuzzball coincidentally to his planning a rewrite of the popular watchfor program — started with discussions of the ways in which Fuzzball would simply not be written anything like it was, were it to be a project begun today.

Speckles, onetime head of progenitor muck Toons, Furr, and Fluff, summarized many of Fuzzball’s deficiencies thus: “MU* server code is based off of 1980s BBS type software. There’s been no real change in how the server operates since the very first [ Fuzzball ] release. Which was who knows how long ago. And it was based off some pretty ancient concepts of communication and data storage. I think this is pretty well known. You can do immensely better with open source modern databases like SQL and a whole new paradigm of communicating. If you want a serious improvement, that’s what you have to do. If you just want something a little more modern, go to Proto or one of the other server builds which has web access e-mail and all that support built in.”

Kelketek, with recent experience on rival software base ProtoMuck, the most recently updated of the major muck server bases, described the state of that system: “ProtoMUCK has an expanded featureset. It is able to make its own network sockets, and attach MUF programs to them, it can communicate with SQL servers, it can manipulate the file system. But it’s already showing a bit of age, MCP support on it is as broken as MCP itself, a simple MPI flaw can kill the server, and it crashed on occasion for reasons I cannot explain or reproduce…”

That this would be a major undertaking was not minimized. Speckles estimated the task as one which asks, “Who is going to take up a full time job for a year or so, to make this work, test, debug and support its launch? And I’m not kidding when I say it’s a full time job. 40 hours a week. If no one can reliably do that, without fail, getting bored, vanishing, having school or other work interfere, then just look at enabling all the more modern web-internet features of proto or something.”

Some of the meeting turned on what features or changes would be liked in a new version of server software. Fluffy held up as example, “I like the idea of writing a whole new server with modern software concepts in mind. And, as I said, using languages other than MUF and MPI as the scripting basis.” Fluffy had noted the ability to embed MUF and MPI as functions of less archaic and quirky scripting languages, allowing the preservation of legacy code, and that it might be possible to have “a way of getting events as JSON or XML instead of plaintext, so that richer [ muck user ] clients could be written, without using the travesty that is MCP.”

It is not planned now or in the immediate future to change the server software on which SpinDizzy runs. It is possible, should this project develop, that it will become something to which SpinDizzy adapts in the future, but that is a consideration for the distant future. And while the possibility of synchronizing muck interactions across multiple servers and media were discussed as things which a new code base could be written to allow, it is not planned or considered that SpinDizzy would change from being a text-based interactive medium. No change in the community’s theme or its OOC, IC, and RP tracks is proposed or will be considered from this debate.