[vworld-tech] Modern MUD server design

[Patrick Dughi]

> You'll want transactions (I think there's a MySQL extension for this)
as
> you mention below, and you'll want to encapsulate them in such a way
> that whoever ends up developing on your platform doesn't have to worry
> much about integrity issues.
	
	The current versions of MySQL offer transaction support only if
you specify the tables as an InnoDB type.  It's still not _exactly_ what
you might be used to if you have used a professional database, such as
Oracle, or Sybase, but it's certainly a lot better than writing your own
(almost assuredly slower) external locking mechanism.

> > - Why a database instead of flat-file/in-memory?  Transaction
> > oriented, fast access, much better persistency, SQL is powerful as
> > hell, access to third party tools, remote modifications.
> >
> This is the rational choice, generally, but one of my greatest
> frustrations in life is watching a production database server die,
> bringing down an otherwise stable service.  It doesn't happen often,
but
> when it does there's not much you can do about it.  Don't hesitate to
go
> hybrid with data that doesn't need to be as dynamic as what a real
> database offers.

	Having worked with large (terabyte) databases for the last
couple of years, I can assure you that every database will eventually
crash.  The same is true for hard drives. It's almost guaranteed within
2 weeks if you're running on anything Microsoft, and maintain moderate
use (I've had much bad luck with Microsoft's 'production' products, like
SQLServer).  The longest I've had a single heavy-use production system
run without interruption was on Oracle 7, on a HP-UX system; about 8
months with daily/weekly maintaince.

	The 'trick' is simply to run multiple replicated databases, all
on RAID disks, and usually use a hardware solution to provide for
transparent failover.  

	Pretty expensive, especially for the sort of redundancy required
for stability, but you all know the saying: you can have it cheap, fast,
and reliable - pick two.

> > - Why C?  Actually, I'm suing .cpp files, however I really don't
care
> > for C++ as a language (something I really don't want to get into an
> > argument about...again), but there are some elements of C++ that I
> > like that C89 doesn't support (specifically, declare-anywhere).
> >
> If it's a platform such as I'm envisoning, the choice of language for
> implementation of the kernel is much less interesting than the
scripting
> language you choose.
> 
	I'm in agreement here.  Most existing scripting languages
already provide for extensibility and integration with software written
in any given language.  Lua stands out as one of the forerunners in my
mind, with a host of other above-and-beyond-basic-scripting features,
like precompiled code.

	There's a few responses to this, and I think it's better to
continue my thoughts on the kernel/scripting language division in
response to those.  Suffice for now to say that it is the scripting
language that I personally think should receive the most attention; the
kernel should be basic, concerned with server I/O, base graphic engine
(if required), and other sundry items.

	PjD