[DGD] Persistent Users

[Raymond Jennings]

I think that user objects/account objects should be persisted.

On Wed, Sep 21, 2016 at 1:04 PM, <bart at wotf.org> wrote:

> Hmm, the current universe of Way of the Force has accumulated 8 years and
> 11
> days of uptime in its swapfile/state dump, and didn't lose a thing during
> that
> time. The codebase does still use save files for both player stats and user
> data (name, password etc), but those are only used when starting a 'new
> universe' (so, starting the driver without state dump).
>
> There is no reason to not trust the swap file and state dump, but getting
> your
> code to always deal correctly with upgrades to data can be a challenge.
>
> Its not so much the mechanics which are difficult, but making sure you take
> care of all changes to your data model all the time.
>
> At any rate, I use user objects as 'session objects', which require getting
> destroyed when a session ends. I keep the user data in persistent objects,
> (and in .o files on Way of the Force, but my current lpc project does not
> use
> .o files anymore for anything)
>
> Way of the Force keeps player objects around for their data, when a player
> is
> offline, those player objects are kept in an out of game area, and
> restored to
> their previous location when the player returns (not realistic, I know,
> but it
> works fine for the setup there).
>
> Bart.
>
> On Wed, 21 Sep 2016 11:07:22 -0500, Blain wrote
> > To me, nothing pertaining to a player should be in memory when they
> aren't
> > around.  Their user object and body aren't usually part of the story
> > or necessary for other players.  In my lib model, I save everything
> > to disk. I don't trust the swap file, especially not with a player's
> > hard work.
> >
> > On Sep 21, 2016 10:59 AM, "Gary" <gary at mups.co.uk> wrote:
> >
> > Hey all,
> >
> > Assuming a mudlib has separate connection, user and player body
> > object(s) (Phantasmal for example has a separate player body)
> >
> > For persistent muds, the player body never needs to be saved out when
> > the user disconnects. It just remains where it was left (or moved to
> > a meat locker etc).
> >
> > What I was pondering earlier today is whether there's any reason to not
> > also make the user object[^1] itself persistent.
> >
> > This would avoid the need to save out the password (and any other
> > user account data that is added). Cloning of the user object would
> > then only occur when no user object exists in the userd for that
> > name. Destroying would only occur for actual account deletion.
> >
> > Over time you could end up with a number of inactive user object hanging
> > around in the swap unused. However, that would appear to be the same
> > problem you face with unused player bodies and could likely be dealt
> > with via the same mud policies.
> >
> > Other than the increase in inactive objects am I overlooking a major
> > flaw with this idea?
> >
> > Cheers,
> >
> > Gary
> >
> > [1]: The hard-coded kernel "admin" user would continue to use a .pwd
> > file. ____________________________________________
> 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd