IntroductionThis page should track the current focus of development on Cantrip. DetailsRight now the most important issue is to attain feature parity with the last released version of Cantrip (v0.8a16). In order to do that we have to solve a number of issues. The largest issue right now is the world data storage mechanism. Historically this has just been an NSMutableDictionary that is provided to Plugin objects and serialized to disk at save. This is a poor method for two major reason: - It offers no automated "undo" support for the Settings panel (more on this later)
- Most importantly, it suffers from "class infection". Suppose the following: a user installs a plugin that makes use of custom classes as their data model. User saves some of these objects to the world data store, and writes them to disk. Then the user removes the plugin and attempts to read the world document from disk. The decoder will be unable to do so because it lacks all the classes needed at runtime to decode the objects. We need to fix this.
Additionally the Settings panel needs to be redesigned/rethought. A description of the issues related to this will be forthcoming. Development TeamAdditional developers are welcome. Please contact James if you have Cocoa development experience and would like to join the team.
|
Sign in to add a comment
I suggest using one of more XML files to replace the serialized NSMutableDictionary.
This isn't a bad idea. Reading XML is exceptionally easy using the NSXMLDocument class, and would provide greater flexibility for data inspection at runtime. This would, however, require quite a bit of extra engineering, but I suspect there is no way around that one :-)
Actually, NSArchiver, NSKeyedArchiver, NSUnarchiver, and NSKeyedUnarchiver should be able to handle most of the heavy lifting.
see http://developer.apple.com/documentation/Cocoa/Conceptual/Archiving/Archiving.html
Cantrip uses the archiver classes, but stumbles over the case where plugins are removed from the application and aren't available to load objects from the archive. If I recall correctly, the archiver classes didn't have very good error handling so it was impossible to fail gracefully on parts of the data that were missing objects, and still load the rest of the document. Essentially what needs to happen is data from various plugins needs to be compartmentalized, and if any of the data fails to load (or is missing the plugin from which it can be loaded) we just skip over that chunk and move on to the rest.
It seems to me that the best ways of doing that would be to either use bundle file formats, using an individual file for each plugin, leaving the plugin writer to handle the loading and saving, or use a single file format that stores each plugin's data in a raw format that can be passed off if the plugin is available to load it.
Just curious, is coding still being done on this project?
I'm also curious about how Cantrip is coming (if at all) because it was truly the best MUD application on Mac OS X. I have a Tiger partition on one of my external drives just to use it, but would LOVE if it came to Leopard.
I have to agree with the last two comments. I still use Cantrip, but running it on Leopard for some reason is much slower than on Tiger. Unfortunately, I don't keep a Tiger partition just to run Cantrip!
Is there anyone currently working on Cantrip?
Thanks!
Andreas, you have it running on Leopard? I know it launches, and I can connect to my MUD, but any input makes it crash. 1GHz G4.
Still wanting a new version of Cantrip! Hope someone is working on it. :P