[ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint)

[Carlo Wood <[e-mail]>]

On Sun, Dec 06, 2009 at 05:11:51PM +0000, Morgaine wrote:
> It's not up to us to prejudge nor prescribe how VW applications will be
> structured.  The fact that advanced ones will involve multiple disjoint
> processes is a given, and our protocol endpoint design must take that into
> account, or it will be obsolete before it is even ready.

I'd like to grab this opportunity to recall my proposal for
client-server protocol negotiation.

I really, really think that this is very important.

If we could get the protocol completely right and finished
the first time and it would never have to be changed again
in the future, because it would suit every possible future
demand and desire, then sure, we wouldn't need this...

However, apart from that the fact that we'll make mistakes,
we certainly can't predict what will be needed in the future!

Therefore we really should allow for protocol changes by
means of negotiation of optional and mandatory protocol
features.

I also think that we should use MY proposal for this negotiation;
and not some other "protocol negotiation" that just won't cut
it once things really start to change.

To recall:

* The protocol negotiation would allow to shift the protocol
base over time to a COMPLETELY arbitrary new protocol (that
garantees that any possible future demand CAN be met).
* It is possible to keep backwards compatibility for as long
as desired (ie, a few years), at which point old clients
may be forced to upgrade if they lack then mandatory protocol
features.
* The proposal comes with a well thought-out sheme of
distributed documentation of the protocol (extensions):
For documentation purposes there would be the need for
one central website having links to the websites
of every administration with protocol
extensions/enhancements (and from there to documentation
of each feature separately).

Leaving out the details for now, as they don't really
matter imho. Not until we agree that this is something
that we want.

Having such negotiation defined, the protocol can and
will be subject to an evolutionary process: Client coders
will think of new features; certain VW's will implement
and support those - and the best features will, under
user demand, be copied by other grids. Once every grid
uses some new feature and every viewer supports it,
the feature can be made an integral part of the protocol
as if it had been from the very start of it's design.

As an example (from IRC (I have been the main developer
and coder for undernet IRC for seven years)): In 1993
I introduced "Time Stamps" on undernet to battle net.riding.
Today every IRC network uses time stamps, and it's
unthinkable that IRC would work without. Other extensions
that I added on top of the RFC which have slowly been
copied by other networks*) are: bans stop every type
of channel flooding; SILENCE stops private flooding at the
server of the sender; delayed joins (to allow large
event channels with thousands of listeners); "max targets"
flood limiting (to slow down mass spamming to one message
per 2 minutes); BURST message to synchronize channels
on net.join atomically; numeric nicks to stop seven types
of possible desyncs as a result of changing nicks in
combination of MODE's, etc. But here it stopped... and
left me very frustrated about the protocol: IT TURNED OUT
TO BE IMPOSSIBLE TO MAKE NEEDED IMPROVEMENTS! Why? Because
for subsequent essential improvements I needed to change
the client-server protocol and that was IMPOSSIBLE because
of the lack of a good client-server protocol negotiation.
(After I left, this negotiation was added, but in a bad
way, still not allowing for the changes that are really
needed).

-- 
Carlo Wood <[e-mail]>

*) Not literally, but the Idea: each IRC network is
   a completely isolated set of servers, often running
   their own private server versions, so there is no
   need for any kind of compatibility there.
   That is different for the client-server protocol,
   since the SAME clients connect to different networks
   (but, as said before-- for a long time any such
   negotiation was lacking; resulting in hackish ways
   to "detect" on what network one was ('undernet',
   'efnet', 'dalnet') and then guessing what features
   are needed (as no versioning was being done) for
   a long time, with uncontrolled wild growth as
   result.
   VWRAP will exist of many servers and viewers by
   *different* administrations/groups that all
   interconnect however! In that case a good protocol
   negotion sheme IS needed, from the very start!