[DGD] Where did all the players go?

[Dread Quixadhal]

One suggestion I could offer is to provide “wrapper” classes that act as handles, or go-betweens, for the actual classes that do work.  The idea is that a piece of user code should very rarely need to directly inherit from the deep API, but should instead inherit the thin wrappers, which themselves will go inherit other things.  Think of it as the difference between a pointer and a handle.

A pointer directly points at some chunk of memory.  A handle points at a pointer, which in turn points at the chunk of memory.  The difference is, if your code uses the pointer, it will break whenever the resource gets updated, as it will end up at a different address and every reference needs to be updated.  If your code uses the handle, that will always remain valid, as it will be pointed to the newly updated resource without user code having to make any changes.

I think you might be able to do inheritance the same way, in a dynamic system anyways.  You may still need to recompile the whole chain, but at least the user code won’t need to change when you break /lib/foo/blah/thingy.c into /lib/stuff/bit.c and /lib/otherstuff/bobs.c, since your wrapper /lib/wrapper/things.c would be the only thing user code knows about.

Sent from Mail for Windows 10

From: Raymond Jennings
Sent: Monday, December 11, 2017 10:01
To: All about DGD and Hydra
Subject: Re: [DGD] Where did all the players go?

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