On Friday, October 24, 2003, at 10:17  AM, eric wrote:

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).

It seems that you're a bit of a realist as well.  I think that a newer protocol would benefit the DC community at large, but for now, we should work on modifying the current one.  If we dive right into trying to decide a future protocol, I think that could easily rob "us" of any momentum we have.

In short, I think that agreeing on a $Supports standard is probably the preferable way to extend the current protocol.  Once that's in place, we'll have an easier time rolling out things such as QuickList ( http://dcplusplus.sourceforge.net/wiki/index.php/QuickList ).  I this might largely be in agreement with what you said, but if not, feel free to correct me.

If you want to start thinking about another protocol, DJ_Offset (already subscribed?) wrote this suggestion:
  http://murdoc.extatic.org/dctng.html

I believe Jon has a binary protocol suggestion in mind.  I think Opera may have done some work on an alternate protocol too.


Other ideas tossed around the Dev Hub (dchub://surfnet.mine.nu:1416) are among the following: making two types of commands: broadcast and directed.  Every existing DC command should fall into one of these two categories.  The commands would be constructed in such a way that the hub can just route and re-broadcast them (possibly with some delays or reordering?).  Another suggestion was to adapt or adopt the IRC protocol, and use CTCP to implement those things that wouldn't map well from the DC protocol.

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, ...).

If you take a look at the latest BCDC sources, Cologic has a Tiger Tree Hash (TTH) implementation well on its way to production quality.  (I think this has advantages of the CMD4 code that I saw in DCTC, and the first-couple-k MD5 in DCGUI-QT.)  I think it would benefit the DC community if hashes are made the de-facto way of identifying files and of searching for alternates...  If we added some swarming features to the clients (tracking known downloaders and existing sources), it'd be wise to re-evaluate DC++'s autosearches.

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 ?

Based on the way you phrased that, there's really no way to oppose that point, is there? :)  I'm all in favor of getting something tangible to the users short term.  ($Supports + Quicklist perhaps? or ClientID? Or perhaps clients just cooperating with BZList, file lists, and small files.)  Once we do that, perhaps it'll be easier to move on to heavier subjects.

 - Todd
DC++ Contributor