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