[DGD] Where did all the players go?

[bart at wotf.org]

Way of the Force is in many respects a classic lpmud, and still shares some
code and design with the classic 2.4.5 lib.

The only way I've managed to make in-place recompilation and data upgrading
work properly is ensure I'm essentially the only person ever doing upgrades of
code on the live mud, and have everything go through a test copy to verify the
upgrade process. Now, WOTF is kindof dead, as I haven't really be doing
anything for it beyond fixing some bugs for the last decade, but for those the
same still applies. Fix code, pay attention to data, ensure any changes to the
data model are reflected in code to upgrade the data, verify on test copy (so
make the conversion code produce explicit output about what it is doing) and
only move things to the 'live' copy after that.

But, with that, and despite the original code working against this, it has
managed a persistent game with uptimes of a decade.

LPCDB is a completely different can of worms. Here I had no legacy to
consider, and any persistent data is kept in objects dedicated to that task.
This makes writing conversion and upgrading code easier, as it is well known
where this data lives, and how it should be modified. Abstraction and only
allowing access with getter/setter functions make managing data conversion
easy. On the flip-side, its data is extremely complex (making the actual
conversion code often quite complex), and giving up some uptime to revert a
bad upgrade is typically not an option there as it means throwing away
relevant data.

Now.. the challenges of upgrading a live system tend to be somewhat unusual
for classic MUDs, but its not at all unusual for those dealing with databases
a lot, especially when combined with an online system which should always be
available. The classic approach of bring down application, run conversion,
start application simply won't work for the likes of google, facebook and what
not. Rolling upgrades are the norm there, which means you actually get
situations in which both old and new versions of the code run at the same time.

Anyway, versioning your data and code in a way you can use from lpc, and
providing (temporary) compatibility with multiple versions of data and apis
seems like a lot of extra work and puts some limits on what you can change (or
requires more steps to make some changes), but it also allows for more robust
upgrades. For lpcdb and other systems which can run in a distributed fashion,
there actually is no upgrading unless you do something like this.

Bart.

On Mon, 11 Dec 2017 07:00:29 -0800, Raymond Jennings wrote
> I'm actually struggling with this "upgrade in place" process myself
> with kotaka.  Trying my best to make it as idiot proof as possible,
> and also try to avoid as much hassle as possible for end user code.
> 
> Add to this that some of kotaka is designed to be inherited and not
> just called...and you have an API maze to help your end users 
> navigate if anything needs to change.
> 
> On Mon, Dec 11, 2017 at 6:47 AM,  <bart at wotf.org> wrote:
> > I think this is a good idea.
> >
> > One of the stumbling blocks for people starting with DGD is the amount of
> > effort and knowledge it takes to actually get started. Packaging it such that
> > people can deploy DGD and a mudlib in a 'ready to go' way, and such that the
> > basic installation and running environment will be similar or identical for
> > such users can help a lot with that.
> >
> > While that was a different era, without the ease of pre-packaged containers,
> > creating a 'just download and run this' experience was one of the things I've
> > tried to create when I was maintaining Gurbalib. Its why it came with an
> > installer, included a version of DGD it was tested with, and in general tried
> > to just get someone running and focus on the mudlib and mud development.
> >
> > 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 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.
> >
> > Another part however is the sheer complexity of supporting in-place upgrades
> > even when people skip inbetween versions, and making it work with the wide
> > variety of things people tend to do once they start using some piece of code.
> > This complexity easily gets in the way of making progress with the lib because
> > of possibly breaking things for others.
> >
> > Regardless, a pre-packaged, 'download and run' distribution will imo remove
> > one of the major stumbling blocks, and seems like a really good idea.
> >
> > But... be prepared to also provide some form of support to those users, else
> > it will not get very far. That means helping users dealing with the more
> > unusual aspects of DGD and their first steps in modifying things to their
need.
> >
> > Bart.
> >
> > On Sun, 10 Dec 2017 22:48:03 +0100, Felix A. Croes wrote
> >> DGD's development has always depended on user feedback.  In its
> >> heyday, 50% or more of bugreports and feature requests/suggestions
> >> came from users, with the remainder coming from myself and from muds
> >> that I was associated with.  Right now, that is less than 5%.
> >>
> >> One obvious reason is that users tend pick a version of DGD that
> >> works well enough for them, and then don't upgrade.  DGD is quite
> >> stable in its core feature set, so these users provide almost no
> >> feedback; more recent features are not picked up and go untested.
> >>
> >> This could be solved by releasing DGD as a package, which is kept up-
> >> to-date along with the remainder of the system.  But I think most people
> >> want DGD + a mudlib, and a package manager is a poor match for a mud,
> >> especially a persistent mud.
> >>
> >> For this reason, my thoughts are turning instead to a Docker container.
> >> The Docker image would provide a startup configuration for an "app",
> >> that being DGD plus a mudlib.  Inside the container, DGD would be
> >> kept up-to-date automatically without downtime using hotbooting.
> >> The same could be done for the mudlib, although this would be more
> >> tricky since local modifications would have to be handled somehow.
> >>
> >> Forcing Docker containers onto existing users is obviously nog going
> >> to work, but I'm looking at using this setup for the AC server.
> >>
> >> Regards,
> >> Felix Croes
> >> ____________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> > --
> > http://www.flickr.com/photos/mrobjective/
> > http://www.om-d.org/
> >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/