[DGD] Where did all the players go?

[Raymond Jennings]

I am curious if DGD's codebase itself would need to be maintained separately.

I also remember that, for a while, the kernel library was originally
part of DGD proper.

Would this new direction be kinda-sorta a way of recombining DGD with
an example mudlib or...would it be kinda different?

On Sun, Dec 10, 2017 at 1:48 PM, Felix A. Croes <felix at dworkin.nl> 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