# [SUG] Two changes to the server

Erik Ostrom (eostrom@research.att.com)
Mon, 28 Jul 1997 18:42:50 -0400

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > (2) This has been suggested before, but can we finally expunge all
    > remaining vestiges of "player" from the server (replacing it with "user")?

    While I understand the desire to rid the server of game connotations, I'm not sure "user" is such a good term either.  Currently the main significance of "player", as far as the server is concerned, seems to be "network connection".  Connections are read from, notified to, connected and disconnected.  While "user" would be a better term than "player" in a MUD-as-workspace environment, it wouldn't be much of an improvement in web servers.

    In most core databases, "player" ends up taking on a far greater significance--standing for all sorts of notions about ownership, identity, location, and so on.  But all that doesn't have to be tied to what the server calls "player" (*)--it's happened due to a combination of decisions in the server and in databases that may not all have been wise.

    In fact (and now you'll see why I'm making such a fuss), I've been experimenting lately with a system in which "person" and "connection" are separate objects.  When you first establish a connection to the server, the listener immediately creates a connection object and logs you into it.  Then you might use usernames and passwords to establish a link between this connection object and a person known to the database; or you might proceed without a known identity, for certain activities.  You might have more than one connection associated with a person at any given time.  Finally, when you disconnect, the connection object is recycled.

    In this system, the `player' variable is rarely used; when it is used, it refers to a network connection.  This works pretty well, and it clears up some dilemmas I've had in LambdaCore and its descendants.  (Of course, it's created new dilemmas of its own.)

    None of this is an answer to your question; I just think it's interesting to think about.

    --Erik

    (*) Except that the server ties identity to "player" somewhat by treating the .name property specially on is_player() objects.  But I think that's a bad idea, too.