Call for Opinions: MIGE

[Chris Lawrence]

On Nov 25,  1:13am, Jon A. Lambert wrote:

> > Ahh.  That's the one thing I refuse to allow: my code to run on MS
> > platforms.
>
> Heh.  I am hearing rumors of Visual Basic for Muds with ActiveMUD controls
> and MudOLE2 support.  The license agreement allows you to serve
> 5 players.  You may purchase additional licenses for every 5 players you
> add to your mud.  Of course for these players to connect remotely, you must
> purchase the Enterprise Edition with RemoteMudObjects...and $$$ and $$$   ;-)

<chortle>

> Well the Watcom SQL driver does handle transactions and rollbacks.  It is
> not one of the faster engines around but it does have a very, very small
> footprint.  456K to be exact and it runs as a separate thread.  It also
> does its own memory caching which can be tuned with an application specific
> configuration file.

Sounds almost like an mSQL derivative.  Every so often I look at the idea of
using a pre-packaged DB layer for the server (I have a copy of DB2/2 lieing
around here unused) -- which is one of the things that got me looking at Texas,
Yooda, tdbm etc.  Most of the MOO/Mush servers are based at some level on dbm.

So far I haven't found anything that really catches my eye.

> I did take a good look at YOODA.  It does a lot of what I want to do.
> Porting is way too big a task for me and the code is heavily UNIX dependent.

Yeah.  There are also a couple basic design points which I suspect would cause
it to thrash under my server (I tend to small objects and large working sets
for transactions with a (comparitively) rate of transaction failures).  The
distribution support is nice, and I think more extensible than what I am using
now.  Their nested transaction support is also a little flakey as far as I can
see once you get past two levels of indirection (not difficult) if the nests
happen to span multiple databases.

> If I find the Cygnus group has done a good port of it, I'll probably
> reconsider it.  For now I'm writing a wrapper around my ODBC API calls.
> This wrapper will be easily replaceable should I find something better
> with no changes to the mud driver.

This is the tack I'm moving to.  My current DB layer is very tied into my
execution and event model largely due to some early bad design work on my part
in handling the guts of transaction contention (what transaction referenced
what, modified what, is ready to commit, and thus invalidated what other
transactions?).  My current though has a single class representing the entire
DB interface with a little under a dozen total entry points with all the
transaction contention handled inside the event model (the way it should have

> I am proceeding on the theory that
> a good deal of my mud can be essentially  disk based, the mud driver code
> need not care where the object happens to be stored.

For me, eveything is disk based.  No permanent values are kept in RAM without
shadowing them to disk.

> The DB wrapper may
> map it to a memory structure and/or into the SQL server which may also
> cache the objects.  Why spend time reinventing these sorts of things when
> they may have already been done.

Teach yourself the concerns of the area.  Lighter weight.  Performance.  For me
the major purpose of thsi project is as a learning experience and
proof-of-concept for various ideas I come up with.

> > Something you may be interested in:
> >
> > The MUD Design mailing list has been running informally for over 2 years.
> >...
>
> I sure am.  It sounds like there might be more on-topic information to
> be found there.

Traffic is woefully slow of late (I was a major participant but had to drop out
for the last month or so due to RL).  To subscribe, send a message to
majordomo at bug.belgonet.be with a body of:

  subscribe mud <your_email_address>

I look forward to seeing you there.

--
J C Lawrence                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...