Decisions, Decisions

So there it was:  The first decision.

And for a programming project, that decision is often what language to use.  Quite often, the language is dictated by the project itself.  But other times, just about any language would do.

For this project, a text-based game library and MUD built on it, I had quite a few options.  I had previously worked on TigerMUD in C#.  I could fall back to that project, or start an entirely new codebase.  My day job requires a lot of PHP and Javascript.  PHP isn't ideally suited for the job, but could do it.  Javascript has recently become more as an actual programming language, and not just a scripting language.

But instead I chose Ruby.  My initial reasons were:

• I wanted to learn it.
• I had previous used it to make a MUD proxy to allow regular telnet access to a proprietary MUD.
• It has a lot of libraries, almost all of which are very open on their licensing.
• It has the built-in ability to reload code from disk while running without any hassle.

Those reasons were about equal, actually.  At least, at the time.  The last one is the most interesting, but also the least useful after all.

In TigerMUD, we spent a lot of time and effort making the MUD able to load the code from disk, recompile it and replace the currently-running code without kicking off any users.  There were many roadblocks, including a memory leak that forced us to partition our code more strictly than we wanted.  See, any code that was loaded was added to memory.  It didn't replace the existing memory locations used.  And to free that memory again, you had to completely dump everything in that partition.  We did it, and it worked very well when we were done, but it was quite the hassle.

With Ruby, you simply tell it to include the code again and you're done.  No muss, no fuss.  However, there's a caveat:  Enabling that means leaving your code open to some attacks.  Your code has to run at a lower safety level, and that's inherently dangerous.  It's probably possible to make your code secure enough that it is acceptable, but it seems too risky to me.  At least for now.

Instead, I plan to solve that problem a different way:  The system will be able to transfer MUD data between servers without interruptions.  To reload the code on a server, you move all the players, NPCs and rooms off the server and onto another one.  Then you bring that server down and back up, with the new code.  Then it can take some data and the next server can do its upgrade routine.

Before I get to that point, I may find another way yet to handle it.  And if I do, I'll weigh the options at that time.