mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [Mldonkey-users] eMule Mod to emulate mldonkey


From: Mike Jones
Subject: Re: Re: [Mldonkey-users] eMule Mod to emulate mldonkey
Date: Sat, 11 Jan 2003 02:02:20 +0000

mldonkey.org might work if it was less segmented.

Anyway...

I vote for: all 

I want a credit system.  I want slot assignment based on client type. And I 
want the standard upload/download ratio speed limiter from the original edonkey 
client.  

Have them all in mldonkey with a proper upload queue and let the user decide 
which she wants to use. (All completely separate of course and easily 
selectable.) 

Plus, consistently offer what every other client offers.

It is easy to modify source, easy to do lots of things, but most people are 
lazy and too busy to care about modifications if what they think is fair is 
already easily accessible to them in a default setup.  

People on emule like to press a button -> set priority to release mode.  It is 
fun and "feels" good to the user.  

mldonkey needs to understand more from a user perspective, not always 
exclusively from a smart algorithm perspective. (although these are great too 
from an "under-the-hood" point of view) You will never come up with a single 
"best" solution that works for all.

BTW, anyone read this: (next overnet=hybrid?)

http://forums.edonkey2000.com/phpBBovr/viewtopic.php?t=44460

-----Original Message-----
From: Stephane Goulet <address@hidden>
To: address@hidden
Date: Fri, 10 Jan 2003 19:50:15 -0500
Subject: Re: [Mldonkey-users] eMule Mod to emulate mldonkey

We allways repeat the same thing over and over again here...

We should somehow vote to express our opinion.. I don't know where, but
since we have been kicked out of ed2k forums and the user base is growing,
we really need a new "official" home for discutions and votes...

On this topic we have mostly 2 questions left..

- Dynamic slot attibution by client yes or no?

I vote yes for reasons others and i stated..

- Allways give a slot for none, M or all clients?

I vote for none, this becomes obsolete with dynamic attribution.

Of course this works until the new authentification scheme is "cracked"...

Per client capping/favorising gives "arguments" for the loudmouths, we need
to steer clear of that and fight back directly at their "community string"
systems and others.

Feel free to prove me wrong ;)







reply via email to

[Prev in Thread] Current Thread [Next in Thread]