Re: Extensions to the protocol.

[Timo Sirainen <tss@xxxxxx>]

> Since the client is going to have to wait, it should probably
> default to short (10 seconds?) timeout, or no timeout, if it's
> sure that the server supports it.

10 seconds wait every time some server is connected? I'd never do that
myself, 1 second at maximum. But of course if the server is busy I could
easily miss the notice then. And specifying for each server if it supports
or doesn't support that feature isn't that good idea either.

> I think the easiest thing is that the server just sends some
> numerics on connect, to say what it supports, but I have no idea
> how certain clients, or servers, are going to react on that.
> The client could then send the commands based on that.

I don't think clients would care much. Efnet servers send notices while
authenticating, maybe they could be used if numerics happen to break things.

> We could also send those numerics after the clients asks for
> them, specially if just sending them breaks things.  Some clients

This makes client wait again.

How about this:

c: pass, nick, user
s: numeric/notify: options blah blah
s: ping server (the normal ping without any weirdness)
c (optionally): reply to options request
c: pong server
s: 001, etc.

The ping/pong part being imporant, when server receives pong it knows the
client didn't want to respond to options request. Without it either server
or client would need to wait for some time to be sure the option
requests/responses weren't missed. I don't think this could even break
anything.