aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: too much feature request i'd like to have  (Read 3221 times)

barbapapa

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 10
too much feature request i'd like to have
« on: April 14, 2004, 02:38:49 AM »

well if i can ask for our x-mas request feature  :rolleyes: let's say :

1 :- i would like something like ipfilter.dat but for "file id" it's not funy to download the same-stupid-file-who-is-not-what-i-want  3 time because it existe with 3 or 4 name.

2 :- something like 'regular expression' for file search a or/not/and, it will be easy sometime to find the good file.

3 :- a mean to activate "source cleaning" only when there is a lot of file source, with only 4 source i don't think it's a good idea to "source droping" even with 9000 on queue.

4 :- probably to much cpu cost but queue ranking is not a perfect way for get a time advancement, i'd like a "shceluder  on rank advancement" if a file with queue on 400 but one hours after he is on 300 it is a lot beter than a 150 and 145 two hours after. it's a probleme with powershare/lowshare and 5kb to 100Mb speed line...

5 :- well since i'm day dreaming, i supose it can just request a mean to get specifique information on file like -language- and -time to be first realeased-. well i supose it depend on all *mule programmeur and server but...

6 :- a mean to specifie a 'groupe of file' well what i mean is most of time if you want  a serie of avi 1 2 ... n, you'd like to have the num 1 first and probably the one who has got number 1 may have the other. so the idea is "try to get first one before" and "ask for the other file of serie".

 :D i know i am not raisonable on feature request...  :rolleyes:

and since i'm here : felecitation!  amule 1.2.6 are realy a great programme...
Logged

Jacobo221

  • Hero Member
  • *****
  • Karma: 3
  • Offline Offline
  • Posts: 2712
Re: too much feature request i'd like to have
« Reply #1 on: April 14, 2004, 03:50:58 PM »

heh. that's quite a little lot :-P
Currently all affords are in getting a bug-free v2 final release and haveing complete support for MacOSX, *BSD and Win32 (apart from Linux, of course). So, I don't think any of that can be implemented in short. Anyway, you can be sure they'll some day be discussed (although soem are technically impossible, as you already said ;-) )

Thanx for those ideas!
Greetings!
Logged

JonathanShields

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 10
Re: too much feature request i'd like to have
« Reply #2 on: April 15, 2004, 02:43:38 AM »

Quote
1 :- i would like something like ipfilter.dat but for "file id" it's not funy to download the same-stupid-file-who-is-not-what-i-want 3 time because it existe with 3 or 4 name.
It's done on eMule. It would be enough to save on your known.met (or whatever) the hashes of all files you've downloaded. And clean it sometimes, to avoid that file becoming too large. Sounds easy... :)

Quote
2 :- something like 'regular expression' for file search a or/not/and, it will be easy sometime to find the good file.
Clients have very little to do with this, as searches are done serverside. Maybe or/not/and searches, but not regexp searches, I'm afraid. :(

Quote
3 :- a mean to activate "source cleaning" only when there is a lot of file source, with only 4 source i don't think it's a good idea to "source droping" even with 9000 on queue.
Agreed. Although I don't think high-queue dropping is a worthy feature.

Quote
4 :- probably to much cpu cost but queue ranking is not a perfect way for get a time advancement, i'd like a "shceluder on rank advancement" .
Sounds good. I don't think an acceptable heuristic (linear/quadratic extrapolation?) is too cpu-expensive.

Quote
5 :- i supose it can just request a mean to get specifique information on file like -language- and -time to be first realeased-. well i supose it depend on all *mule programmeur and server but...
Yep. It mostly depends on server and protocol. The best you can do is trust on file comments, and comment files you release/share.

Quote
6 :- [...] if you want a serie of avi 1 2 ... n, you'd like to have the num 1 first and probably the one who has got number 1 may have the other. so the idea is "try to get first one before" and "ask for the other file of serie".
Yes. But this depends too much on file names. And file names often hide numbers, so parsing them would not be easy. Right now, I suggest you the "rude" way: add new files for that serie on paused mode, and swap any A4AF sources to those you want first.
Logged
C combines the power of assembler language with the ease-of-use of the assembler language.

Jacobo221

  • Hero Member
  • *****
  • Karma: 3
  • Offline Offline
  • Posts: 2712
Re: too much feature request i'd like to have
« Reply #3 on: April 15, 2004, 02:56:22 AM »

>> 2 :- something like 'regular expression' for file search a or/not/and, it will be easy sometime to find the good file.
> Clients have very little to do with this, as searches are done serverside. Maybe or/not/and searches, but not regexp searches, I'm afraid

True, but some regular expression search could be done locally, as a filter. So, "^[lL]ord" would search for both "Lord" and "lord" and then erase from the output all wntires which do _not_ start the filename with oen of those words. Of course, "Alice*" will never be implemented. At least there's no way I can think of :-)

>> 6 :- [...] if you want a serie of avi 1 2 ... n, you'd like to have the num 1 first and probably the one who has got number 1 may have the other. so the idea is "try to get first one before" and "ask for the other file of serie".
> Yes. But this depends too much on file names. And file names often hide numbers, so parsing them would not be easy. Right now, I suggest you the "rude" way: add new files for that serie on paused mode, and swap any A4AF sources to those you want first.

No way to do this, but apart from "high" "low" "normal" and "auto", there could be a "relative" (or something like that) option, which would let preferences be sored by numbers between some files, so those files have preferences between themselves. More over, this relative preferences should be able to work on parallel with other gorups of relative preferenced files. Quite a difficult feture I guess, but, hey, it's a "future" request... not inmediate ;-)

Good to see future requests are discussed between users.
Regards!
Logged