You're Invited

Introducing a new product to the world is always a special pleasure for me. This past weekend I assembled an ad-hoc rapid development team with the objective of building a task management system that could handle a large number of items spawned from numerous sources (click the link above to read a description of the principal behind the system). I am pleased to announce that we have completed our initial alpha prototype, and would like to invite anyone out there who thinks they have a crazy todo list to join up and give it a spin! Keep in mind this is an ALPHA system whose CONCEPT is not even a week old! That being said, there are a few things to know.

First up, we have a bugzilla install at http://bugzilla.scramdac.com, and would really value feedback and bug reports.

Second, you'll need a few tips to get started:

Queues
This system is designed to track your tasks based on their real world sources, and the relative priorities of those real world sources. For example, a weekend project or personal project would be of a relatively lower priority than say, your work tasks, or coursework. Therefore, it is necessary to create at least one queue with at least one relative priority value. Relative priorities are the reverse of what you would think they are. That is, a priority 0 queue is the HIGHEST priority, not the lowest. I would suggest creating a queue with a priority of 10 first, then you can make your additional queues higher or lower priority than that queue (higher being a lower number, and vice versa). It is easy to adjust these priorities later.

Tasks
The bread and butter of the system is the set of tasks that you enter into it. Each task is associated with a given queue, and assigned a "importance" level. Importances are single letters from A-Z, with A importance items being of the highest priority, and Z items being of the lowest priority. You can also enter a description for each task, and an estimated time to complete it (this does nothing right now, but will soon be leveraged for some upcoming features).

ToDo List
The tasks are aggregated into a ToDo list and sorted by a mixture of their importance, and the relative priority of the queue that they are associated with. That is, an A level item from a low priority queue will be lower down on the list than an A importance item from a high priority list. I could explain the algorithm that is used to generate the list, but it is not easy to do so without a graphic, which currently only exists on notebook paper. I will post one soon with a more thorough explaination of how the algorithm actually works in the near future. In the mean time, just experiment until you end up with a balnace that makes sense!

So please! go ahead and give it a try! We would love to hear your feedback on this. Keep in mind that our objective was to create a useful task management tool. Anything beyond that would be pure coincidence (see the blog link above where the product is described for more information about the motivations).

Take care,

Thought Experiment: Using MySQL for working memory

Several friends of mine have recently expressed interest in creating a new MUD project. MUDs are kind of neat, especially for developing and testing game design and balancing principals, but are generally not commercially useful or very good at retaining value in the long run. However, they do sometimes give rise to a few interesting programming / implementation questions.

Recently I've been wondering if MySQL might be useful for creating a virtualized shared working memory subsystem to replace RAM and flat files in the context of a MUD. Let's consider a typical data structure.

MUDs consist of worlds made up of MOBiles, Players, Objects, and Rooms. Let's consider a Room. Rooms can contain Players an Objects (on the floor) as well as Mobs and room programs. These associations are typically stored as null terminated doubly-linked lists of pointers in memory. If the mud crashes, all of the data which has not been written to one of the flat files that store the players, rooms, etc is lost when the memory is purged. Further, building any kind of redundant or load balanced system is a challenge without having to rebuild the entire architecture of the system.

If, however, a MySQL database were used to store all of this working memory information, crashes would become less painful, parallelization would become easier, tool development would become easier (interface with the database rather than the MUD application) etc. What would be the drawbacks? Obviously performance, loss of control over validation (it's never good when validation code is replicated in more than one part of the system) the potential for invalid states to rise in an effectively persistent memory (the database) leading to a greater chance of data corruption, and the lack of a sane method of event based updates to the data. That is, an event recorded on one system in a parallelized environment may update the data that all of the other nodes would be referring to, but without any of the associated triggers in terms of data to send to connected players.

This then regresses into consideration of an event system configured in a shared memory environment (again, a database could be adapted to this purpose) but then raises the question of which system should be the one to write to the memory, causing a fallback onto a required elected master/slave failover system which has potentially wiped out any complexity savings that previously seemed apparent in using the MySQL database for parallelization in the first place.

So what value is there in the conclusion of this thought experiment? For one, it doesn't seem to make sense to hammer the square MySQL block into this round parallelization issue hole. I for one still wonder if it would be possible to design a subsystem that would achieve some of the desirable features of such a shared memory subsystem using MySQL as the backend datastore. However the point is ultimately moot as the performance of such a system would be so miserable as to be impractical. There already exist a plentitude of solutions for this problem all of which are probably superior to using a shared relational database for virtualized shared memory.