Ämne:Re: [dcdev] New Encoding Scheme First
Till:Direct Connect developers <[email protected]>, [email protected]
I see no reason to mandate that new hubs support both the new and old
encodings, and certainly not indefinitely. DC client turnover is quick
enough that I'd be comfortable in a few months with dropping support for
the old encoding, for example, in any hubs I'm involved with.
CR should not be a separator; I find multiline message support valuable,
for example, for ensuring pasted source code is nicely formatted.
XML, of course, avoids the problem with the proposed CR-delimited message
format, and I find it preferable. Further, the suggestion to use lzo (or
even zlib, depending on overhead; I know lzo has significantly less, but
zlib's improved compression may be worth it. Something to consider),
renders XML quite bandwidth-friendly. It has the additional benefit of
encoding commonly used nicks and command and such concisely after it's
built up a dictionary, beyond just the XML tags.
However, I'd prefer an a binary encoding to either of those, as a means of
resolving the currently extant divide between a socket mode for
transferring files and one for transferring commands. This may be an
aesthetic point, but I find that quite unelegant. If one is going to
homogenize the rest of the protocol encoding, leaving out the file
transfers themselves strikes me, at least, as a conspicuous omission which
should be justified. Mandating purely textual content, UTF-8 or not, would
prevent such a unification of the protocol, and as such should be avoided.
By contrast, a protocol designed to natively handle binary data would be
quite capable of dealing with file transfer data itself in a common
framework as the commands itself, and is thus an improvement over a
text-basis for a P2P file transfer protocol.
Finally, DC has many semantic, rather than syntactic, limitations, and
whilst replacing the syntax certainly aids towards fixing the broken
semantics by creating a more extensible environment in which to introduce
improved semantics, I feel that one should take the opportunity created by
breaking compatibility to introduce functionality such as: standard
GetZBlock-type download support, hash support, search ID support, and
various other flaws described at http://murdoc.extatic.org/dctng.html.