Very Usefull Feature Addition ("Sticky Queues")
Moderator: Moderators
Very Usefull Feature Addition ("Sticky Queues")
Ok, here is my idea. *fanfare please*
Why not allow a user to manually enter a queue by specifying the search keywords, file type, and size(at least, at most, normal). This queue will become a "sticky queue" which will constantly remain in the queue and, given 'auto alternate search' is enabled, constantly scan for new files matching the criteria. When it finds a match, it queues it and once it downloads the filename and filesize are added to a 'dupelist' to prevent the file from being downloaded twice.
What good will this be? Some examples:
1: LamerX likes to watch hippopotamus have sex, he needs the clip to be a decent length so he can get his wack on. A "sticky queue" is generated to match 'hippo sex', file type video and at least 4 megabytes in size. LamerX can now get his pr0n fill, automated style.
2: LamerY is after a release, he knows that the rars of said release are named 'arelease.r01 through .r49'. A "sticky queue" is generated to match 'arelease.'. DC++ will effectively download the entire archive, with you only needing to setup the one queue. Same goes for a missing file of an archive, create the "sticky queue" and you can sit back and not constantly have to search the hubs for the missing file.
3: LamerZ likes movie releases done by 'UNNAMED' group. A "sticky queue" is generated to match 'UNAMED' with at least 500 megs in size. LamerZ goes away for the weekend, comes back, and has a bunch of movies to watch.
The list goes on..
Is this not the single greatest thing you've EVER heard of? Of course, it will have it's issues, for example, the silly user that decides to sticky queue '.' and loses all his RAM to his DC queue , but i'm sure limits can be set. If you agree with me let it be shown and maybe we'll get a nice a new future feature. If you disagree with me, feel free to voice your opinions and generally tear apart my idea, k thx.
:: KEEP IT FREE! ::
Why not allow a user to manually enter a queue by specifying the search keywords, file type, and size(at least, at most, normal). This queue will become a "sticky queue" which will constantly remain in the queue and, given 'auto alternate search' is enabled, constantly scan for new files matching the criteria. When it finds a match, it queues it and once it downloads the filename and filesize are added to a 'dupelist' to prevent the file from being downloaded twice.
What good will this be? Some examples:
1: LamerX likes to watch hippopotamus have sex, he needs the clip to be a decent length so he can get his wack on. A "sticky queue" is generated to match 'hippo sex', file type video and at least 4 megabytes in size. LamerX can now get his pr0n fill, automated style.
2: LamerY is after a release, he knows that the rars of said release are named 'arelease.r01 through .r49'. A "sticky queue" is generated to match 'arelease.'. DC++ will effectively download the entire archive, with you only needing to setup the one queue. Same goes for a missing file of an archive, create the "sticky queue" and you can sit back and not constantly have to search the hubs for the missing file.
3: LamerZ likes movie releases done by 'UNNAMED' group. A "sticky queue" is generated to match 'UNAMED' with at least 500 megs in size. LamerZ goes away for the weekend, comes back, and has a bunch of movies to watch.
The list goes on..
Is this not the single greatest thing you've EVER heard of? Of course, it will have it's issues, for example, the silly user that decides to sticky queue '.' and loses all his RAM to his DC queue , but i'm sure limits can be set. If you agree with me let it be shown and maybe we'll get a nice a new future feature. If you disagree with me, feel free to voice your opinions and generally tear apart my idea, k thx.
:: KEEP IT FREE! ::
Well, that should'nt be hard for a seasoned programmer to get around. One way would be to limit the max number of results that a sticky queue returns(say 50) and at the same time check each result against the 'dupelist' so that it does not count a dupe as one of the 50 results and as more files download, more of the 50 results are free'd up allowing new queues to be created.Too bad you mentioned the "." flaw, cuz I would have been all over that one baby!
But then again, it should be the user's responibility to not choose a search query that will return an absurd amount of results.
-
- Posts: 3
- Joined: 2003-05-22 15:03
well patch submitted to arnie (though I'm not hopefull on it being added) the patch is at http://twink.orcon.net.nz/patches/AutoQueue.diff if anyone else wants it.
(note: This is a very primitive Queue system, and probably will cause problems if you aren't very specific with ur adl searches (ie it doesn't check if the file is already queued etc)
(note: This is a very primitive Queue system, and probably will cause problems if you aren't very specific with ur adl searches (ie it doesn't check if the file is already queued etc)
-
- Posts: 3
- Joined: 2003-05-22 15:03
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
hmmm well heres a few ideas I had to improve my patch, thought it might be worth some discussion
1) Check if file already in queue before queuing it (ie use it as an alternate)
2) Put Autoqueued items in a special folder (so you can easily check what was added)
3) Have option to set priority of autoqueued items (ie paused, so you have a list to go thru but they dont auto download)
4) Make sure it works with arnies auto download list thing in 0.305.
1) Check if file already in queue before queuing it (ie use it as an alternate)
2) Put Autoqueued items in a special folder (so you can easily check what was added)
3) Have option to set priority of autoqueued items (ie paused, so you have a list to go thru but they dont auto download)
4) Make sure it works with arnies auto download list thing in 0.305.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us