TTH is the standard

A new version of DC++ is out; 0.696. It is a… quite aggressive version. It now require that all files have a TTH. No files without TTH is shown in the search and you aren’t able to download any file that doesn’t have a TTH. TTH is the standard now and all is great.

7 Responses to TTH is the standard

  1. emtee says:

    And more aggressively it removes all items from the queue which doesnt have a TTH so those items must be finished with the old client before upgrade. The final chapter of compatibility changes.

  2. Fredrik Ullner says:

    Nah. The final chapter is when NMDC is totally ripped out. :)

  3. enksksi says:

    why not send all nmdc-stuff in utf-8? you have already broke down the entire nmdc-protocol so none of the original nmdc clients don’t work. and DON’T SAY “THERE’S ADC”.

  4. What breakages are you referring to? If there are any, I suspect they’re a side effect of DC++’s growing dependence upon ADC.

    Sending text as UTF-8 would break chat display in hubs centered around (for example) Japanese or Russian speaking users until all of the users upgraded, and I imagine other functions would be similarly impaired. I’m not sure there’s anything current that causes that level of interoperability issues.

  5. enksksi says:

    What breakages are you referring to?

    “* Removed support for generating NMDC-style file lists (old clients won’t be able to download from you)”

  6. That’s a point. The statement was slightly inaccurate, since they could download, just not browse your list (similar to the situation with trying to get 0.401’s list).

    Changing client to client communication is an entirely different thing than changing client to hub communication, as sending everything in UTF-8 would be. Years ago, a dozen or so people from various hubs and clients talked about it, and the consensus was to make a new protocol. Collaborative design was tried for a number of months, and then arne decided to take what he considered the best ideas and spin them into ADC. One of those ideas was Unicode support from the outset, so you wouldn’t have to wonder how various hubs and clients would (or could) break upon receipt of UTF-8 data instead of data in their local codepage. I think the possibility of bringing UTF-8 support to the NMDC protocol is very remote, as it would be a reversal in the direction that DC++ is taking.

    I think that compatibility with the “original NMDC clients” is a red herring. The most important interoperability concern is with non-DC++ based clients. To that end, all of the changes to DC++ have been documented so that developers can add support to their clients. I think that’s pretty reasonable, certainly more so than many other programs. The number of users running DC++ is large enough that other developers probably have a natural drive to maintain DC++ compatibility.

  7. Pingback: The case of a missing tree « DC++: Just These Guys, Ya Know?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: