Uhm, this might have been sent twice, but I didn't get it back so I'm
sending again...
---

Oh, sorry, I didn't know about it...anyway, there are a few points in there
that were discussed in the client-client extension protocol and that formed
the current implementation, I think that was before your appearance...I
guess they apply here as well:

1) Versioning: Superflous, specially the .xx part...confusion could arise
where x.01 should support x.00 as well and so on. This is after all just a
way of getting the client's attention, which imho shouldn't need to change
very often, and if it does we screwed up badly the first time and should
call it something totally different anyway.
2) Lists in lists for supports: Dropped in favour for easier parsing of the
list, any lists in lists can be negotiated later (ie protocols for secure
connections, ssl for example negotiates the protocols itself as a part of
the standard), and most commands don't need this anyway.
3) , as separator: Why another one? There are already 3-4 different ones in
the protocol, and the space is arguably the easiest one to read. (this is
where I admit my mistake with the <++ tag and , =)

-- and here's some new ones --
4) Why a different scheme between client-client and client-hub? It adds to
the confusion...
5) $Supported in the end doesn't really do anything, I mean the hub sent
what it supports, the clients did the same so all they have to do is
intersect the two lists, adding a totally different command for this adds to
parser complexity.

Regards /J

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Gustaf Räntilä
Sent: Wednesday, October 22, 2003 9:44 PM
To: 'Direct Connect developers'
Subject: SV: [dcdev] (no subject)

This one http://gempond.com/dcext.txt

Gustaf