Re: [Mldonkey-users] alternate temp file system, plz

[kami petersen]

devein wrote:

> i wouldnt call it "reversing" .. in fact, these days any big emule feature
> implemented in mldonkey is one more step towards modernisation... (which
> features you would like that other p2p clients have?)
>  
so wouldn't it be closer at hand to help out the emule folks? or, if you 
don't like them, make a new branch of it (even a new emule would 
probably reach out to end users faster than any mldonkey-for-windows 
effort would) and make it really good. there really shouldn't be any 
need for to competing softwares in open source... mldonkey and emule do 
different things, for different people. if your goal is to create a 
better p2p-experience for the windows user, can you please (for once and 
for all) tell me why mldonkey code base is a better starting point than 
emule code base? now please note that i'm really not trying to be 
offensive here. i even tried emule a while ago, didn't find it half as 
bad as thought it would be, however it is lacking some of the  features 
(real ones) that mldonkey has, if you see my point =)

> im a fan of mldonkey, but i keep my opinion: mldonkey in current state is
> not usable for desktop systems & average desktop users.( mldonkey as linux
> daemon - im running it for a long long time... )
>  
you mean "desktop systems" as equal to windows i presume? linux users 
should really be fine i think, especially with the über-cool g2gui =)

> (or maybe we should look at mldonkey as we look at vi or emacs? "robust,
> does his job,many features, comfortable to use for those who studies their
> settings & advanced features, etc ;-)
>  
yep, that's where i think mldonkey belongs.

in conclusion:

my point is that mldonkey and emule should compliment each other, not 
compete (this only increase flame wars, the amount of silly 'features' 
etc.). if mldonkey should be maintained for windows, i think it really 
should cater for the 'advanced' user who leaves his box on 24/7 and 
needs it to be a quiet, secure, stabile, memory efficient *service* (as 
opposed to application). now that's a *real* challenge, and a viable 
"business idea".

kindly,

kami petersen