[DGD] Where did all the players go?

[Dread Quixadhal]

Does the DGD driver have command line arguments to hotboot a running instance of itself?

One very convenient way to package it for Linux systems would be to utilize their package manager’s pre and post-install scripts, so you could have it (optionally build and) install the new executable, and then run a command to force any running instances to hotboot themselves.

Obviously, a few details would have to worked out.  New config files would overwrite old ones, but this already happens with other system packages, and you’re usually asked if you want to keep the old one, the new one, or view a diff and possibly edit during the install.

I’ve never used Docker, but I guess it’s a viable solution as well, probably the best option for Windows users.

There’s also the possibility of releasing VM images, but that really is just a pre-packaging of the OS package manager solution, in something that’s already installed, but will still need to update itself.

I think any mudlib (except the kernel itself) would just need to be handled by the folks running their games… far too many variables to touch anything beyond the config file.

Sent from Mail for Windows 10

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

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
____________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd