[MUD-Dev] Re: openmud: open issues

[Vadim Tkachenko]

James Wilson wrote:
> 
> I'd like to set down the design issues that have come up, in short pithy blurbs.
> Please add to this list:
> 
> 1. implementation language: C/C++/others?

Any, provided they all modularized and support the common communication
protocol.

> 2. target architectures: posix/Win32/others?

Does it matter?

> 3. threads: emulated in-core? using native threads? no threads at all?

"TheThread" abstraction. If it doesn't exist for a selected combination
of language/platform, too bad - probably you made a wrong selection.

> 5. module system: what goes in the core, and what comprises a module?
> how do modules interact?

see (1)

> 6. distribution: should an explicit design goal be to support a distributed
> mud?

Yes

> what are the requirements?

See (1)

> 7. database: disk-based DB? distributed DB?

"Storage system" abstraction.

> is this invisible to the programmer?

Yes.

> what is the DB model (object vs relational vs ...)?

Doesn't matter

> could there be multiple DB's?

Why not?

> 8. memory management: garbage collection? explicit allocation/deallocation?

At least some kind of smart pointer with a mark-n-sweep or reference
counter, the latter is better in the languages like C++ where it's
possible to have static/automatic objects behave as their dynamic
counterparts (explanation will follow if there's enough demand; I had a
very stable implementation working exactly the same for MS-DOS, Windows
and OS/2, only Java prevented it from existing in UNIX incarnation)

> 9. overall goals. 'a really fast mud'? 'a really scalable mud'? 'a really
> usable mud'? 'a really advanced mud'?

A really extensible MUD

> James

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are