[DGD] just out of curiosity

[Shentino]

I don't know what to make of this sudden conversation that has
divebombed my inbox...but I guess I could throw in my own two cents.

If I had to make a guess as to the lack of dgd's uptake in the mud
community, it would be the differing api between DGD and lpmud's,
namely the lack of actions, containment, and so on.   Personally I
think DGD is better off without all that cruft being hard coded,
though for the lazy and/or less technically minded it is a migration
barrier since it prevents a simple "cut and paste" replacement of the
server program, and at a minimum requires a side trip into compiling,
configuring, and bootstrapping dgd.  The mudosalike layer helps with
that somewhat.

However, Vkikingmud semi-recently migrated to DGD and were quite happy
with the results, so the rewards of migrating are hardly anything to
sneeze at.  And my own project, kotaka, is proving to be interesting,
and was designed from the beginning to run with the kernel library and
dgd, so I am avoiding some of the barriers that may well plague
traditional muds.

As far as dworkin's personal life...well, I do consider him a bit of a
celebrity in the mudding world, considering that he's written an
awesome driver and I've had the pleasure of minor personal talk.
However as a human being I consider him entitled to the same deference
and privacy and whatnot that any person would naturally expect in a
civilized world, so I allow my curiosity to be self restrained.  Like
most personal stuff in gneeral, it's only as much my business as he
sees fit to make it.  Given how little of it is actually relevant to
dgd, were I to get curious about it it wouldn't be over this mailing
list.  I'm sure Linus Torvalds, another obvious "big person" in the
geek world, has his own cross to bear wrt. being a celebrity.

Regarding the distinction between inheritables and clonables, I can
tell you first hand that being able to upgrade an object without a
huge cycle of vacate-destruct-reclone-refill is an enormous time
saver.  Upgrades are instant from the POV of lpc code, and I've been
on a mud where I had to fix a teensy typo in a description and wait
for about 5 minutes for the many clones to get recloned in
place...along with reexecuting the creation function in the process
which almost complicates things.

I also agree with dworkin's justification to make upgrades a series of
atomic processes where you recompile one leaf at a time.  It makes
things easier to digest at runtime if you can pick and choose how to
upgrade, instead of being forced to recompile every leaf of a given
library object.  Plus, it's avoiding a minor DoS vector.  There may
well also be a problem in a leaf object that causes a compilation
error if, for example, it attempts to rely on functionality "upstream"
in the inheritance tree that no longer exists or has been renamed, so
you can't even guarantee that "force all the leaves to update with
you" is even going to work.  You can break a leaf's code without even
touching it.  This breakage could also result in a half-recompiled
inheritance tree where you have both the old and new inheritables
existing at the same time, and both of them need distinct entries in
the object table or chaos will ensue.  The only operation that is
atomic is recompiling a leaf object, and it is therefore the only
operation where it is safe to reuse an object table entry.

Also, it's possible to do a dummy clonable that does nothing but
inherit a library, so it's not really that big of a restriction.

As far as text vs graphics, I'm inspired by the SkotOS layer design of
pretending that the virtual world, the text interface, and a
quake-like interface are all three components of a theoretical perfect
mudlib, and that the virtual world needs to present a consistent API
to both interfaces.  I am also taking this approach with kotaka.  So,
it's not terribly difficult to make a virtual world api that isn't
text centric.  The only thing that really needs to be textual is in
game speech, and even then you have options, such as different in game
languages, which could be garbled based on skill differently in a
graphic client vs a text client.

I'm atm working on the SkotOS 2.0 release process as best I can.  it's
a lot to digest but I'm starting to get a feel for the basics.  The
parser at least impresses me.

I think that keeping this notion of a virtual world, a text interface,
and a 3D interface being three separate components that must interact
with a common api will go a long way towards entering the 3D era
without ditching the text era.  Plus being modular is just good OOP
practice.