[833] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: connections

daemon@ATHENA.MIT.EDU (Tue Oct 17 21:40:26 1995 )

Date: Tue, 17 Oct 1995 18:14:10 -0700 (PDT)
From: weber@tungsten.seattle.geoworks.com (Eric Weber)
In-reply-to: <9510172126.AA04556@avon.declab.usu.edu>
To: 869683 Gillespie Brandon James <brandon@avon.declab.usu.edu>
Cc: coldstuff@pippin.ece.usu.edu

Gillespie Brandon James writes:
 > I did consider that, but the question has to be asked: why? 

The "why" is that it is much easier to get fine grain control with
in-db policies then in-server policies.  For example, if I want player
objects to only have one connection at a time, but allow unlimited
connections to a web object, I could do so by putting the appropriate
things in the respective methods.  If the server flat prohibits
multiple connections, I lose.  Obviously, I could work around this by
creating child objects for each connection, and in fact that may be a
better design anyway, but on the other hand I may have a really cool
way to handle multiple data streams from a single object.

To take a different approach, I argue that your dilemna over whether to
disallow the second connection or force the first connection out is a
perfect example of why this should be an in-DB issue.  Whatever
decision you make, there will be some situations where it isn't the
most appropriate model.

To paraphrase the X philosophy, the server should provide mechanisms,
and leave policy to the database.  Just as parsing and security is
handled by the DB, so should regulation of connections.

-- Eric