# connection redirection

ThwartedEfforts (abakun@scinc.com)
Fri, 23 Feb 1996 12:44:48 PST

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

    A few people have sent me personal mail concerning their views with
    redirecting a connection to another object, and everyone hints at the fact
    they have "some use" in mind, but then say they don't want to bore me with
    the details.
    Here are a few reasons, which I consider to be more important than my
    previous arguments.

    --  the network connection *is* the object it is connected to.  This is
    susposed to be an object oriented enviroment, and as such, the connection is
    an object, they are one and the same.  This being the case, the only way to
    bind a connection to a player object should be at connect time, via the
    return value from :do_login_command.  Once that association is made, the
    connection is the object and the object is the connection, for the life of
    the connection.

    --  any kind of 'changing of the function of an object' (or connection)
    would better be done with OO concept such as changing parents,
    addition/removal/programming of methods and altering state through
    properties.  If you want an object to be able to do more than one thing for
    the network connection it is/represents, then the object (or it's ancestory)
    should be programmed to do those tasks.

    Altho, Kipp had a great idea with :handle_input; we already have what he
    describes, but with a less clean interface and much of it being handled by
    the server.  A few points:
    -- I assume the parse() bf Kipp suggests also invokes the verb it finds.
    -- redirect would be fine as long as:

       redirect(fromobj, toobj)
       redirect(#-10, $owner)
       => 0
       redirect(#10, $owner)
       => E_INVARG

    ie, you could only associate unlogged-in connections to valid player objects.
    -- I don't see what :new_incoming_connection and :new_outgoing_connection
    would be useful (but only those names were provided; I can only guess at
    their use)
    -- It will most likely be much easier to implment than it would be to clean
    out the old way... keep in mind that you'll need to remove the 'make sure
    it's the server calling' checks in the verbs on $sys! :)

    This is, overall, a great idea; right now, it's all handled by a close
    interface between the server and the database, using return values from
    verbs to tell the server what to do (return value of :do_login_command and
    :do_command).  Unlogged-in connections should probally still be handled in a
    different verb than logged-in ones.
    Any other ideas?

    Andy