[DGD] Kernel library

[Felix A. Croes]

Frank Schmidt <franks at colargol.tihlde.hist.no> wrote:

> On Mon, 14 Sep 1998, Par Winzell wrote:
>[...]
> > Of course it's perfectly OK if you do not like the DGD-supplied kernel
> > lib, but how exactly do you envision a dependable abstraction layer to
> > function if it does not require mudlib code to be built on top of it? If
> > it does not use auto/kernel object functionality? The entire point of
> > such a thing is to sit solidly between your torches and AI-monsters on
> > one hand and DGD on the other.
>
> The main idea is that it requires mudlib code ontop of it, I haven't said
> anything else. But the kernel lib is far from what I see 'fit' for MUD
> programmers world wide, when lacking lots of "general" functionality to
> handle arrays, strings, mappings, math, sorting algorithms, etc, etc,
> which in my opinion belongs in the auto object. (Previous mailinglists
> explains why) And that's just one of the issues, each time you need
> something special (which you know DGD can offer), a General kernel lib
> will probably not support it.

Your view of what a kernel library should be seems to agree perfectly
with the function of the objects in the /dgd directory tree in the
2.4.5 mudlib -- which is certainly not that of DGD's kernel library.
Beyond that, I think you also fail to understand what the kernel
library can do, as evinced by your earlier comment that it "occupies"
the auto object and driver object.  If there is one thing that the
kernel library is good at, it is modifying or completely overriding
the behaviour of those two objects.

I think that some of this blindness is caused by the extraordinary
success of LPmud 2.4.5.  To get beyond that, let's take a look at
a completely different mud, Ultima Online, comparing features with
those of traditional LPmuds:

 - UO is persistent.

   Persistence is DGD's most important single feature (I like the
   term "continuous mud" better, but "persistent mud" is the
   standard term these days).  A persistent mud needs a design
   radically different from that of a traditional LPmud:

    - There has to be a way to change the behaviour of existing
      objects.  The kernel library is designed in such a way that
      upgrading objects -- that is, recompiling them without first
      destructing them -- is possible for all objects, given the
      limitations imposed by LPC inheritance.
    - If you have guest-programmer wizards like traditional
      LPmuds, you need a way to limit the resources available to
      individual wizards, since rebooting the mud to get rid of
      undesirable objects is not an option.  The kernel library
      has a generic resource management system which manages
      such things as number of objects or number of callouts by
      default, and to which new mudlib-specific resources can be
      added at will.
    - Such functionality as string formatting should not be in the
      auto object.  Having to recompile the 3D space code because
      a change was made in string formatting is ridiculous.

 - UO has a custom client.

   The kernel library cannot make any assumptions about what sort
   of client is being used.  It cannot even assume that everyone
   uses the same client.  It merely attempts to be as little in
   the way as possible -- not only in the matter of communications.

 - UO has no traditional rooms, add_actions, etc.

   All such things have no place in the kernel library's auto object.
   Similarly, nothing that is not needed in <all> muds within its
   target range has a place in the kernel library.

 - UO supports up to 2500 players per server.

   The kernel library is prepared for DGD's multithreading future.
   Ideally, it should be possible to build a mud on top of the
   kernel library and upgrade the kernel library every time that DGD
   is changed, without letting this have an impact on your mud.

The kernel library would be a fairly good fit for implementing UO on
top of DGD.  It would not have to be changed in any way (I have
verified that this is the case).  It would have some superfluous
functionality, such as the wizard support.  On the other hand, adding
guest programmers to UO is an interesting possibility.

Of course, I do not know to what degree UO matches your chosen mud
type.  But the fact that I can use the kernel library to implement
UO indicates, to me, that it is good at what it does.

Dworkin