The Problem (or, why bother?)

As we all know, Mudlet stores all of its profile information in a single XML file. When we distribute a ’system’ or package, we are distributing that same XML file — ideally, without a HostPackage and with only the code and settings that we want in it

The Crucible project is meant to be a team-effort though, and just how to enable collaborative editing of this file is something that’s bothered me. Since some (many, most) of us aren’t going to be actually editing the file -as- XML, but instead within Mudlet, there has to be a somewhat painful series of importing/exporting and sending this file around, integrating changes and such, and all of that actually seems like it would ultimately take quite a bit of time and effort.

One way to simplify it would be to only send diff’s between members, and while that would work, I’m not really sure I like it as a solution. Because there’s other “problems” that the single-file nature of a profile imposes for distribution and packaging, and I think a unified approach to all of these problems in terms of a set of tools, might be a better answer.

Where would the tools live?

The tools are not meant to be integrated into Mudlet directly, nor things that 99% of the people would even care about. Sure, maybe one day, some or most of the functionality might get integrated– but for now, Heiko has better things to do, I think. The tools will all be written in Python, because honestly, I can get it done faster in Python and make it cleaner that way, and let us get to work. If someone wants to port them to Lua, they’re free to do so– as with all Crucible code, they’ll be released under the MIT license.

The Crucible project itself is hosted on Launchpad, and the tools will be as well, as simply a separate branch that anyone is free to download and use.

The tools!

crucible-integrate

The integrate tool is sort of the inverse of my mudlet-release.py script I wrote previously: given an XML file, a profile name, it essentially imports the given file into the profile. But it does so smartly: if any given item already exists in the profile, its replaced instead of having a new one imported.

The benefit of this over a normal import is primarily that it updates instead of duplicates, which is important when working with other people a lot. However, care should be made that any changes you’ve made recently have been committed — it can’t be an intelligent differ.

crucible-split, crucible-join

The foundation of the system of tools are crucibile-split and crucible-join. Split opens a profile XML (either the most current one in a Mudlet named profile, or a file you specify), and goes over — and explodes it into a whole bunch of files in the filesystem, with groups creating subdirectories.

Now, why you ask? Two reasons. One, its more useful in storing in source control once the system gets bigger… I don’t have to analyze a diff to figure out you’re modifying the autosipper, I can see you’re editing the autosipper.xml file. Two, the ability to do rule-based ‘joins’ to build up a resulting package are very, very powerful.

The opposite works as well: crucible-join will go over the source XML’s and reconstitute a complete package, which you can then import manually or use crucible-integrate to basically copy all of the items into your current profile.

Now, I do not expect people to -work- on these “source” xml files. In fact, it’d surprise me very much if anyone did. The basic workflow is thus:

1. So you want to start working on some scripting, right? First you do a ‘bzr pull’ to get the latest sources.
2. Next, you run ‘crucible-join’ with the appropriate option(s), and it goes out and constructs a package of the latest stuff from everyone.
3. You either import it, or better, you run ‘crucible-integrate’
4. You launch up Mudlet, and get to work!
5. Once done, you save your profile and exit Mudlet– or just leave it open, whatever.
6. You run crucible-split, and all your changes are written out in source form– and you commit. Done!

This may seem a bit complicated, but I think it will make the ultimate workflow much easier– and we can build upon it. There’s several additional tools I can imagine building on this basis to make things nice and easy.

crucible-build

Speaking of building upon it There’s a lot of things I plan on doing in terms of Crucible, but not all of it is relevant to all MUD’s. For example, there has to be a different plugin for every MUD just about, even though a lot have common information. So we might have a Lusternia prompt, an Achaea prompt, an Aardwolf prompt, and so on and so forth.

Although the Crucible queue system is actually universal and applicable to anything that’s balance-like, the exact strings may vary from MUD to MUD that you should track for when you recover. Perhaps someone may want an auto-sipper from Crucible, or perhaps they may want it from someone else. Maybe there’s some other feature which may be not always desirable.

The ’source’ storage form makes it very easy for us to set up a series of rules to build a package which has a custom set of modules included in the final package. The crucible-build command in essence is an automated wrapper around crucible-join which can build out several different flavors of Crucible which we can then all upload. ‘Crucible for Lusternia’, ‘Crucible for Achaea’, etc.

The other option to that would be to use what is in essence a required plug-in system…everyone must install Crucible Base, then a module for their particular MUD. I’d rather make it easier for users though, and include everything together at once. Initially, the build program would have to be run by a person then all the files uploaded, but I see no reason why I can’t turn it into a web-app which dynamically generates a Crucible with whatever options a certain person wants, or at least an option to -build which uploads everything automatically when run.

Thoughts?

(the diff of the merge can be found here, btw.)