Ämne:
Re: SV: [dcdev] (no subject)
Från:
eric
Datum:
2003-10-24 4:17
Till:
Direct Connect developers <[email protected]>, Gustaf Räntilä <[email protected]>

Hi,

Before arguing about the need of a command or if one minor thing is better than another one, I think we first should do the following things:
1) define the base of protocol we want to have, like the way to build/encode a command (don't name any command here) with its parameters, the way to establish connection, the command sequence to use to perform task, the way to handle missing parameters or exception, ...
2) define a charset to work.
3) define what are the mandatory commands a client should support.
4) a standard way to announce supported optional commands (a kind of $Support).

I won't propose to evolve to a chunked binary protocol (even if it will definitely discard any incorrect command interpretation due to incorrect separator and it is probably the ultimate solution for optional commands and protocol evolution), it is probably a too big change (but I really like to handle simultaneously crypted and not crypted data in one stream :) ).

My first point is motivated by the infamous $MyInfo with its parameters that are a mix of $ separated ascii values and binary value. A standard way to encode command parameters would have prevented this awful things.

Defining a charset is necessary because not everybody (in fact, only few countries) has a language that only use ascii-7bit and even if lot of users run a client under windoz, I don't think the windows-1521 (or something like that) is good because it cannot evolve to support more than 256 characters. I really think we should move to the standard UTF-8 which AFAIK natively provides support all possibles characters (any characters using '`°"^ as well as cyrillic alphabet and ideogram based languages). UTF-8 seems to be the more logic choice because most of the OS uses it, even if it is more or less hidden in obscure kernel layers.

The 3rd point is IMHO required because not all client needs to support all commands and because not all commands are mandatory, we should have (4th point) a way for each client to announce the optionnal command it supports. Some missing commands seem to be more and more important like connection encryption, file integrity check (corrupted files are really pain in the ass) but I also think these commands must be optional because they can use a lot of ressources (CPU, memory, ...).

I think if we all agree on a common open and clearly defined protocol we should be able to obtain something that can be enjoyable for both developers, hub Ops (Bots will finally be able to sanitize hubs without inaccurate kicks/bans :) ) and users, don't you think so ?

Eric
(DCTC/dchub)
-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev