-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 28 October 2003 11:32, Jacek Sieka wrote:

Some random thoughts on a new protocol:

1) I like the idea about having 2-3 types of commands, type1 -> hubonly,
type2->a specific client, type3->broadcast. This way, new commands can be
added to clients without upgrading the hubs. Each of these commands would
then have a header for the hub, and the rest of the data for the client
(that the hub can check/parse/deny if needed)

Nice idea, adds alot of flexibility, but we need guidelines for implementing new stuff, and a hub may be configurable to not accept certain commands. I'm not 100% fond of passing through "unknown" commands, which in worst case scenario can break clients (although that would be a client bug/hole).

2) I don't like XML. We're running short on bandwidth, so a more
conservative encoding would suit us better imho. CPU btw is afaik not an
issue (dch++ uses about 4% cpu on an average 1500 user hub on a decent
computer, don't remember exact specs, but it's so low that well...), so
perhaps we could use XML + compression if you're fanatic about it, but imho
it's a ferarri when all we need is a fiat...

I agree, but was mostly thinking from the hub point of view. (Thinking about my good old p200 with 32Mb memory taking a few thousand users today in some tests I've run... :-).

3) I don't like a pure binary protocol for many reasons, ranging for hard
to debug to hard to interpret on different platforms due to different byte
order. The w3c hasn't put out any binary protocols for a reason, and yet,
these are the most successful ones out there serving millions of clients...

Yes, a good example here is the H.323 protocol which is a binary protocol ratified by the ITU (International Telecom Union) for VoIP and videoconferencing. This protocol is as complex that several multi-billion companies don't manage to implement it properly. The best known implementations are from Radvision (used in most commercial videoconferencing equipment today), Microsoft (used in Netmeeting) and OpenH323 (open source).
Debugging it is not fun (I've been playing around with it)!
I expect the SIP protocol will gain alot of market share within a few years since it can do the same thing and is a text protocol.

(...)
6) UTF8 is the encoding of choice for me as well...it should suffice for
now, although we should keep an eye open for 4-byte unicode support once
that becomes popular (don't remember if utf8 can encode that or not)

UTF8 supports all kinds of characters (including 2 and 4 byte unicodes) but use generally less space on western european texts. For asian languages on the other hand, UTF16 is the better choice considering space/bandwidth.

In fact, I started writing on a spec for this, taking many good ideas from
jan vidar's dctng.html freely =).

:)

- -- - -janvidar-

Dj Offset / QuickDC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/nm9SMLjmoUcyZAoRAqUqAJ9emJFNSUCBnKFXuXu6ASTqMHp7lACePBWc
TaJI0DSP0QJIzE7O3o5VwZA=
=dwjb
-----END PGP SIGNATURE-----