[DGD] Where did all the players go?

[Felix A. Croes]

bart at wotf.org wrote:

>[...]
> As you mention, keeping the mudlib uptodate this way is more difficult because
> of user changes to that lib. I tried to do a few things to reduce this issue:
>
> - Make things 'pluggable', ie: Gurbalib's safun setup allowed for adding and
> overriding afuns in a way that should not conflict with updates to the lib
> (this is no longer the case in the current version)
> - Strictly dividing the lib in a 'kernel', 'lib' and 'user' part. Only touch
> the 'user' part (which included the safun dir)? You should be fine.
> - Modified the 'lib' part? This should still be relatively easy, but requires
> work for merging changes
> - Modified the 'kernel' part? You are on your own.

This dovetails with my own experience.  I came to the conclusion that you
need a kind of package manager for inside the persistent mud, and that the
OS-level package manager can only mess things up; that is another reason
for desiring the isolation of a container.

What a persistent mud needs goes further than a traditional package manager,
because of runtime upgrading.  I have not yet settled on any particular
solution.


> This worked somewhat, but, people find enough reason to modify the lib part to
> still make this a lot of work for both the maintainer of the core
> distribution, and the users. Additionally, it also meant a fair bit of extra
> work to ensure lib upgrades always worked, or in cases where that was not
> possible, at least ensure they pointed at the proper way to upgrade (requiring
> specific inbetween versions for migrating data).
>
> At any rate, keeping a mudlib distribution uptodate and facilitating in-place
> upgrades of muds using it is a pretty big challenge due to data conversion and
> having to provide ways to upgrade user data, even when people do not modify
> the core lib. 
>
> Part of the issue here is this being a somewhat unusual approach for most
> people. Understanding the in-place recompilation of code is already a bit of a
> challenge, doing proper data conversion seems a bridge too far until people
> gained significant experience with the system.

This is true even for non-mud database professionals.  Mention runtime
upgrading, and they will insist that bringing the database down for
maintenance is a better solution.  Mention hotbooting, and eyes start
to glaze over.

Regards,
Felix Croes