Comment 4 for bug 1451223

The download does indeed show up under the normal transfers. However, there is nowhere that indicates that the download was initiated by a plugin, but I'm not sure if that's useful or not.

Re "data accessor", yes, I had in mind other functionality, such as data (file) access to various setting files (favorites.xml for instance) in addition to the specific HTTP layer. The idea with the "data accessor" isn't specific to HTTP, it was simply that iceman discussed that it would be nice. I am envisioning an update plugin that can automatically update DC++ (including automatic updates for plugins themselves). Feel free to suggest other functionality that may be interesting.

1) Fair enough.

2) You mean like how the current HTTP manager sends ::Updated?

3) Ah, totally missed that. Agreed.

4) After some more consideration, there's no particular reason. It's fine either way.

5) Yep.

Will update and post a patch later on.

By the way, I could not find another way for a plugin to request to download a file synchronously without introducing busy looping or similar functionality. In reality for small files (if the requester knows it's a small file), it might be nicer to have such functionality. Also, because there is a callback, every plugin will get a notification of each file, which might be an information leak.