[MUD-Dev] Re: PDMud thread summary

[Darrin Hyrup]

At 12:47 PM 10/23/98 -0700, Jon Leonard wrote:
>On Fri, Oct 23, 1998 at 01:46:44PM -0400, Adam J. Thornton wrote:
>> I second this.  If it's Posixy, porting it will be much simpler.  

I agree as well.  POSIX with a mind towards safe programming practices
(liberal use of sizeof() for example.)

>There really aren't that many OS features that a MUD needs to use, and with
>a modular design, these can often be isolated.

Exactly!

>I think the only things that all modules would have to be aware of are
>dynamic linking and threads.  There should be compile time options to
>turn those off, too.  (My old computer supports neither, for example.)

We may have to consider some internal threading for mud processing rather
than use OS-based threads in order to be more compatible across platforms.

>Filesystem access and player communications should probably be isolated to
>singles modules, so the effort of porting them to exotic systems should
>be fairly low.

I agree there too.  I would like to see us support multiple communication
protocols in the base distribution.  Filesystem could be a plugin too, but
I don't see that being as necessary... especially if we roll our own db.

>In short, I think portability is important, and with only a little extra
>effort we can make stuff portable even beyond the range of posix systems.
>
>Things we'll have to be careful about for portability:
>
>Endianness (sending data between systems might get mangled)
>64-bit cleanliness (sizeof(int) isn't necessarily sizeof(pointer))
>Threads
>Sockets and other non-blocking IO
>Other things I haven't thought about
>
>Systems that I want to be portable to:
>
>Linux/Alpha (frost.slimy.com)
>Linux/Intel (my laptop)
>SunOS/Sparc (my old computer)
>
>There'll probably be someone interested in porting to Microsoft platforms,
>an probably also to AmigaDos.  Others?

I'd like to see it run on:

HPUX 10+/HP-PA (my development workstation)
Win32/Intel (my other development machine [besides my linux box])

>Still, I think the better approach is to start designing the system to
>be functional, and then profile it to see what needs to be made faster.
>Premature optimization is a big waste of time.

I agree.  We want to be careful not to design ourselves into a circle.
Lets concentrate on basic features, make sure they work together (with an
eye towards optimization later) and begin laying the groundwork.

Best,

Darrin