[DGD] Persistent Users

[bart at wotf.org]

In my case, user objects do not contain any data which has meaning beyond the
session they represent, that data is no longer needed when the session ends.
That session can be telnet, ftp, but also http, and multiple sessions on
behalf of the same user can be active at a given moment.

Because for example http 1.0 does not use persistent connections, and http/1.1
does not guarantee them, separating connection from session is a good idea.
The connection object only deals with the connection specific details, the
session object deals with getting a user authenticated, and connected to
something else for further handling, and contains any data that relates to
that session (such as per session terminal settings, or session id for being
able to simulate persistent connectivity over protocols which do not support
that).

Any persistent user data such as password, privileges etc is kept in a
separate database, and is managed completely independent of any existing user
objects.

But maybe I should rename my user object 'session object'.. oh well, the name
is kinda historic.

Bart.


On Wed, 21 Sep 2016 14:29:17 -0700, Raymond Jennings wrote
> 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
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


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