[DGD] Monkey wrench with Klib's user select

[Shentino]

Here's the oddity:

If you have a user object that called LIB_USER::login (and registered
itself with UserD), then if another connection comes in with the same
name, it goes directly to that user object without being routed
through TelnetD/BinaryD's select routine.  At first I thought I made a
mistake, but then I saw the source for UserD.

Why do this?

I'm just asking, because this "gotcha" turned out to be a HUGE monkey
wrench that forced me to redesign big time.

I was hoping to be able to split my user object into login, register,
and play objects that would use redirects to pass the connection on as
needed.  For instance, TelnetD would have returned a login clone, and
after being authenticated, it would pass the connection to a play
object.  Or, if it was a new user, it would be passed to register,
which would create a new account.

However, with the Klib bypassing select and going straight to the user
object already logged in, the play object would be receiving an
unauthenticated connection, which might not even be correct (clients
can make typos).  AFAIK, the only way to get rid of it is to call
connection and then redirect, which has the unpleasant side effect of
killing the play object's current connection.

I'd like to know why the Klib was written this way.  Some input on the
reasons behind the goofy engineering would probably help me understand
the Klib and find a solution.

Currently, I have a weird "connection to interface" delegation, with
the user objects just standing in the middle playing telephone
operator between the connections and the interfaces.  I would have
liked to cut the middle man out and not play pattycake with the
user/connection system.