> 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.