DC++

So, all of the Stochastic Modeling research currently carried out supports you does it? Perhaps you need to do a little more research before you start throwing entire areas of science at people. Furthermore, saying things such as, "you don't have enough of a foundation for it to even be explained to...

Cologic: You can think slot-usage on a DL-slot-limiting hub would be sub-optimal if you want to. I don't believe this would be the case at all, unless by sub-optimal you mean users on super-fast connections wouldn't get to take 30 slots and hinder slot-availability for users on connections that are ...

In fact, I see no reason why the number of interrupts should be taken into account at all. If anything, that could be left for another option. Just bumping up the priorities of files as they reach certain points in the DL would work very well in my opinion.

To clarify, I think it would be best if the process is as formulaic as possible without having to remember too many previous values.

Ah, sorry for misunderstanding. I have a feeling it would be best to keep the process as straightforward as possible and let users decide whether they would want to turn it on or not. 0-100 priority levels is a good idea to implement into the system certainly, and 50 as the standard starting-point f...

It would be interesting to see how this works. I think the only way to really see is to test it out. I'm not sure I would want to start out all my downloads at lowest priority, but maybe this would work well in the system you describe.

Well, I could see an option, "Change all files at [n]% complete to [p] priority," might be used by a fair number of people so long as they had control over the values of [n] and [p]. In any case, I still see the right-click menu addition to manually adjust DL priority in the current DLs window as a ...

Yes, for the most part it could be that an automated system which takes into account completeness in its order rankings would be effective in doing what I described. There is only one potential problem I see here: if I want to decide priority on a file by file basis and for varying reasons then a ma...

Scenario: I have the option set to automatically bump up priorities for interrupted DLs. There are ten items currently being DLed. Five files get interrupted, and four of these files were new DLs only at 1-10% complete. One of the items was 93% complete. I want the item that is 93% complete to be se...

You don't have to witness anything to use it. All you would have to do is right click and set the priority to whatever you want depending on what you want to occur in the event of being disconnected. If the DL is at 90% and you want it to finish soon regardless of whether it is interrupted, then jus...

Yes, but I am not sure a universal automated option is useful/necessary here. If I am only going to want to change the priority of certain currently downloading files that are close to being finished, then it is not helpful for me to have an option changing all interrupted downloads to a specific pr...

I am not sure you are following my reasoning in its entirety if you think that it solely consists of something along the lines of, 'it's something new about which we can make a rule so why not?' I would suggest you re-read my previous posts, specifically those referencing the advantages for hub newc...

Yes, here is my reasoning on the matter: changing priority for currently downloading files doesn't change a thing at the time, but it would give priority to those DLs that are interrupted. Among other things, this could be useful for those files that you realize are almost finished and just want the...

I thought someone would've suggested this at some point or other, but if it's out there I haven't found it yet. Personally, I think it'd be very useful to have the ability to adjust download priority for a given file from the right-click-menu in the downloads-currently-in-progress window.

Are suggesting that all hubs would require DL slot limitation indicators to be turned on? I strongly disagree. I am certain that quite a few hubs would not require this.

I very specifically addressed the privacy issue in one of my previous posts. To rehash what I said earlier, I believe that privacy concerns are real enough and should be paid attention to. However, in this instance I think the feature enabling users to turn the DL slot limitation indicator off suffi...

In many ways I believe this argument can be boiled down to the following analogy: Capitalism vs. Socialism
I like both ideas, and don't see why they can't co-exist peacefully.

I can see this argument isn't going anywhere fast on either end. I can also see there's a lot of concern about DL slot limitation indicators and how they would probably inhibit people with super-fast connections. I can't say that this wouldn't be the case, but I think my suggested option of being ab...

The day some committee takes over DC++ design is the day it becomes a less useful project. But committees are usually only formed for things so ingrained in the system that they're basically universally accepted. So maybe this would be good in some way? j/k ^_^

I never suggested I wanted the hub to turn on/off the hypothetical DL-slot reporting feature. I was thinking this would work fine as something the user could do from the options menu on their end. I didn't realize that you were specifically referencing programming in your previous technical attack, ...

The problem you suggest regarding most people reporting 0 DL slots would be a non-issue if an on/off function for DL-slots is implemented. If you're in a hub where DL-slot-reporting is required to be on, then chances are the hub would also have a DL-slot limitation requirement (say for the sake of a...

I was just thinking that a possible solution to this issue could be an option to turn DL slot reporting on/off. Then OPs could decide whether they would require DL slot-reporting and/or limiting for their particular hub, and no one would have to be reporting anything extra so long as they choose to ...

No reason to get annoyed, this is just a discussion after all. I don't think most hubs would make rules regarding # of download slots if a download slot reporting device were somehow implemented, but I'm sure a good number would. I don't know if I personally would hang out in hubs that implemented D...

I think adding this extra description is a good idea and here is why: Someone on a very fast connection can easily take many many slots, and then newcomers to the hub find it difficult to get slots due to the people who are downloading 50 files at once. There isn't anything inherently wrong with thi...

Another feature that I think would be useful is the capability to specify download-priority by file-type. Available file-types could be the same as those currently used in the search window to avoid confusion. Here's one example of the benefit of this feature: Say one day you really want to DL some ...

It is certainly true that some of these issues can be handled very well with hub-side tools. One of the main advantages I see to a client-side feature allowing input for back-up hub preference, is that an individual user can decide to enter a different hub than where they would normally be transferr...

I believe one of the main reasons people start using faker clients and slot-lockers is because of the upload issue. This is starting to become a serious problem in almost every hub as less and less people actually have legitimate shares and slots. I'm not saying implementing some kind of upload mana...

It would be helpful if it were possible to enter a back-hub hub in the options for favorite hubs so that, if one were disconnected from a given hub due to a hub reset, they would automatically be redirected to a specific "back-up" hub of their choosing. This could also potentially take some of the l...

I have to agree that upload control in some form is a good idea. I think a reasonable solution is trusting people not to lie about their connection and using OPs to punish blatant abusers. I know this isn't a perfect solution, but it would help people whose upload bandwidth is too crammed to allow s...