Removing Support for Pre-ADC 1.0 Clients in DSHub

[Toast]

Not talking about the software itself talking about DCDev ADCH++ Hub since they dont wanna support old prebased adc 1.0 hubs why should the rest do it

[en_dator]

My opinion is that its up to the dev/dev-team of each hubsoft to decide what they intend to support, but I ask only that they clearly state WHAT they support in the docs so that anyone that is looking for a hubsoft can know wht to get from it.

[adrian_007]

it depends on one const in header - adch++ could ban non-adc 1.0 clients long time ago.
for exapmle, i work on adc 1.0 and i've removed all compatible hacks.

[Toast]

en_dator of course its up to every dev team to decide what to support and not support in their hubsoft still i wanted to do a poll in order so see what the general public thoughts around the subject was and its pretty clear on the line with what i am thinking of.

Here is why i want this done

• 1. i don't wanna repeat NMDC history with old and outdated clients supported by each hubsoft.
  2. Since open software is made to be updated and revised for bugs its the users responsibility to keep themselves fairly updated.
  3. If a chance of preventing old clients/outdated to the ADC 1.0 spec occurs it should be taken up upon so that so that old bugs/(not found) exploits can be prevented there for not repeating NMDC History (thinking of the recent CTM Exploit that was found in the old protocol).
  4. A simple spec can be made for ADC Hubsofts that includes an upgrade msg (detection of client etc, links) in order to bring more stability to ADC Development.

conclusion its not that i think its every users right to run whatever client they want i just think its bad outta a developers perspective. I think at the current time could and should do better features now when the time is right to do so before everything becomes old stuff.

Thats the reason why i started to discuss this topic in order to get ideas for new features not just a simple block system per say more of a upgrade system in general that helps a user to get on track to upgrading.

• user connects
• adc version check
• client check
• upgrade msg (with link)
• disconnect (optional)

This is what ive come up with so far, this i think would be an excellent model.

[Pietry]

If the client does not send BASE in it's initial support string but BAS0 ( a pre 1.0 version ) then it should be disconnected with an upgrade message. Seems quite simple. Any client who sends BASE ( meaning they do actually support or at least pretending to ) should be let in until they do something not according to latest specs...

[Pietry]

ADCH++ isn't about a "fix" . This is not a bug. ADCH++ intentionally lets older users in. Also, ADC was intentionally created so that it's backwards compatible ( at least in a way ) so that NMDC problems don't happen again. This way, older clients can use newer hubs and viceversa.

[Pietry]

* user connects
* adc version check
* client check
* upgrade msg (with link)
* disconnect (optional)

I don't agree with the client check . The VE string is just informative, not something to discriminate about. Having "++ 0.699" in the Ve string doesn't mean the client has ADC1.0 or not. Just that we " know " it doesn't doesn't sound enough to me. One could mod 0.699 , add ADC 1.0 and keep the version string.
The discrimination factor should be the initial SUP string and the SU field in the client's INF. That's the place where one could see if the client supports BASE or not . And of course, by the way the client behaves. If incompatible commands are being sent, hub can disconnect anytime.
I also do not agree with sending the user to some webpage according to their VE string. It's virtually the same stuff, plus the possibility of bad address and again discrimination because of the hardcoding of the strings ( one can never have all the clients on the market hardcoded in the hubsoft ... )
Hope that my opinion seems clear...

[adrian_007]

of course it should not be checked against VE field, just drop support for BAS0 clients.

btw it could be done by client profile, script or plugin, in both sides - hub and client (op)

[Toast]

i would like to hear from the 2 persons that voted against and hear their arguments for keeping pre adc 1.0 clients

[Mythrael]

i would like to hear from the 2 persons that voted against and hear their arguments for keeping pre adc 1.0 clients

Well, it's simple "Man think about all the ppl that cant get in", many people use old clients like the ancient rmdc or older versions of dc++. The majority of dc++ is represented by ignorant people who have no desire to upgrade their clients and many of them might not even know how to set up a client.

I think that, for starters, people should get a warning message in their clients to inform them about how old their client is, and after a month or two, support for old clients should be cut off, but not before that, they should be warned otherways they might stop using dc++ entirely.