aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: 1 [2]

Author Topic: webserver or maybe daemon bug  (Read 7585 times)

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: webserver or maybe daemon bug
« Reply #15 on: October 22, 2005, 07:38:21 PM »

Quote
wtf keys have different names there ?!
When we have an option to decide what keys we want to use, I believe they should be clean and self-explanatory.

amule.conf is a big mess as it is now. If you first saw "PasswordLow", what would you think it is for?
Unfortunately we can't expect to clean up amule.conf, because
1) backwards compatibility
2) eMule compatibility

Still this doesn't mean that we have to clone this mess on a new config file.

Quote
We have dedicated config file for remote tools, called remote.conf - lets be consistent and use only this one.
People may want to access amule core on more than one computer from the same computer (not necessarily at the same time), so we have to provide means to use any file as a config file. "remote.conf" is just the default.

Quote
I think easiest way would skip step (2), i.e. pressing OK button should update content of remote.conf.
I don't agree. Why should an application (over)write the configuration file of another app?
Logged
concordia cum veritate

lfroen

  • Guest
Re: webserver or maybe daemon bug
« Reply #16 on: October 22, 2005, 09:05:42 PM »

Quote
People may want to access amule core on more than one computer from the same computer
May I ask from what planet are you writing this ?! I may imagine scenario when I access my mule from different locations. But I can't even thing about opposite: having 2 mules at home. Please, don't waste your time explaining me that it's possible from technical point of view. Most chances it is and it doesn't matter - 1% of users with such demands will find the way, but other 99% (me including) want things to work on first attempt.

Quote
I don't agree. Why should an application (over)write the configuration file of another app?
I'll tell you "why". Because this would eliminate countless questions in forum "I have changed password, but can not login". It confuses users - so this must be bad. And btw, this is not "another app" - :)
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: webserver or maybe daemon bug
« Reply #17 on: October 22, 2005, 09:52:18 PM »

Quote
Originally posted by lfroen
Quote
People may want to access amule core on more than one computer from the same computer
May I ask from what planet are you writing this ?! I may imagine scenario when I access my mule from different locations. But I can't even thing about opposite: having 2 mules at home. Please, don't waste your time explaining me that it's possible from technical point of view. Most chances it is and it doesn't matter - 1% of users with such demands will find the way, but other 99% (me including) want things to work on first attempt.
Just a simple case: One may have a mule(rabbit) running home an at the school/company/whatever. He'll most likely want to connect to the *other* mule, not the local, so the local shouldn't overwrite remote.conf. (Unless this man is masochist enough to always type the config file name on command line or wise enough to create a shell script (Oh, no!! Shell scripts are evil instantiations from Hell!!!!) to work it around.)

Quote
having 2 mules at home.
And, ehm, I never said "at home".
Logged
concordia cum veritate

lfroen

  • Guest
Re: webserver or maybe daemon bug
« Reply #18 on: October 23, 2005, 09:15:27 AM »

Quote
Just a simple case: One may have
That's exactly why I asked not to waste your time. Yes, you right, "one may have blah blah", and this is about 1% of amule usage. Make most common case use work smoothly, and then worry about corner-case scenarios.
Logged
Pages: 1 [2]