Re: qlimit

> This would be an argument for having the server block when the clients
> have trouble keeping up.

But we are talking about two important points on other axes here.  Firstly,
we are deciding the semantics of the file change notification interface in
the general case, not just for console.  Second, servers blocking is an
issue of robustness in the face of broken or malicious clients.  It's
unacceptable just on robustness grounds for the server to block its general
functioning (i.e. changes to a particular display) arbitrarily subject to
waiting for some random client.  Something that would be acceptable in that
regard would be to only block/queue notifications to a particular port--so
the server doesn't block at all necessarily, and it never blocks things
other than more notifications to the same port.  That still has an issue of
arbitrary queueing storage in the server to get al the changes to an
arbitrarily slow client (e.g. one blocking forever).  I think it just
doesn't make sense to try to make the notification mechanism perfectly
reliable for too-slow clients with the burden all on the server.

> There are only two ways to reduce the number of RPCs: Group multiple
> rpcs into one or change the semantics.  The former makes it harder for
> clients to display changes incrementally, the latter is only of limited
> use.  I could for example have a normal screen matrix notification also
> have the meaning: "check the current cursor position", this would half
> the number of RPCs for the common case.

The major kind of semantics change you could make would be to use less
message passing and more shared memory.  This is one of the classic ways to
reduce exactly this kind of overhead.  That is, the change notifications
can be relatively rare (e.g. only one ever queued) and just serve to alert
you to examine the shared memory area for updates.  If you want to have a
full record for incremental updates, you can use a shared memory area that
encodes a log in your own format.  That too is not fully synchronous in the
sense of the client never losing an update, unless the log expands
arbitrarily (which you could do).  But you could make the log a large ring
buffer and easily have more than enough backlog space than you ever care to
worry about.