[834] in Coldmud discussion meeting

Re: connections

daemon@ATHENA.MIT.EDU (Wed Oct 18 01:16:30 1995 )

From: brandon@avon.declab.usu.edu
Date: Tue, 17 Oct 1995 23:05:11 -0600
In-reply-to: Your message of "Tue, 17 Oct 95 18:14:10 PDT."
 <9510180114.AA19146@tungsten.seattle.geoworks.com>
To: coldstuff@pippin.ece.usu.edu

< 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.

It depends upon the viewpoint being taken.  Right now it _IS_ this way,
with a few "loose ends", one of which is that multiple connections
can be using a single object.  The problem with this is you dont have
multiple connection control, and frankly I dont see the NEED for it,
since you do have the controls available for single connections.

If we do have multiple connections to a single object, how would you
suggest the interface?  We could have all of the connection methods
send a first argument which is a 'connection id', unique to that
connection, then send to that connection id.  Of course, then people
would just want to send to the connection id without binding the connection
to an object, which gets really hairy... (other than language rules
and encapsulation, there is no reason why connections are bound to
objects--when you currently send to a connection it steps down a list
of connections until it finds the one(s) associated with your dbref).

What I was suggesting is primarily a tightening of the control, you have
full ability to control connections in any way you want right now, in-db;
I was just talking about the odd case where two connections would
accidentally get bound to one object (I've only had it happen one of
the times I rewrote $network).  Basically the i/o from both connections
gets sent to the same object.

Actually, the main reason I would like to do it this way is simplicity.
It is simpler to provide the mechanisms for 1/object and to let people
code up mutiplicity in the db, than to do it in the driver.  Furthermore,
as I start to add files as well as connections, I would like a standard
between the two, and this seems the way to go (in general I have found
that the simpler design is usually the better one anyway)...

-Brandon Gillespie-