https://bugs.gpodder.org/show_bug.cgi?id=462
Thomas Perl <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |WORKSFORME --- Comment #3 from Thomas Perl <[email protected]> 2009-12-16 23:52:57 GMT --- (In reply to comment #2) > I understand this may require refactoring of code and that it's not a > short-term priority, but does that really make the request invalid? Not really, but right now, I do not really see myself implementing this, as for most users the current download limit feature works fine (I've set it to less than 3 most of the time, for example - and on Maemo 5, the value is fixed at 1 at the moment). The question would also be how to "detect" the same server? Via its DNS name? What about servers with virtual hosting (same server, multiple DNS names)? Ok, then - via its IP address? What about round-robin DNS - based web servers? It's not that easy for a client to implement this without much effort. I don't even know if download managers (i.e. application specialized in downloading) have this feature. Another reason why I believe that the current download limit is already fulfulling this request is that servers tend to have more bandwith than clients. Given this, there's little reason to set a per-server limit lower than the global limit for the client (e.g. having a "max_downloads_per_server" of 3 and a "max_downloads" of 9 would not make much sense when the client has less bandwith than the server, and so the three downloads are probably already saturating the client's bandwith, leaving less space for the remaining 6 slots - a global download limit of 3 would achieve about the same effect). Changing the resolution to "WORKSFORME", as the current download limit works for me and basically does the same thing. Even though I like your idea, we're lacking resources to implement this feature right now. Again, if someone comes up with a patch, I'll be glad to review and merge it. Thanks for your feedback. -- Configure bugmail: https://bugs.gpodder.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ gPodder-Bugs mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-bugs
