The reason that FCPv2 supports a global download queue is primarily so that clients can start downloads, and hand them off to the global download queue, at which point they can be managed by FUQID and other download managers supporting the global queue.
This requires that the downloads be able to complete on their own, or that the client polls the global queue, or that it gets a notification. The first option is easy to implement: use ReturnType=disk. This is easy, but it doesn't work if using remote FCP, unless there is a shared filesystem. This does however have some major advantages, so we should continue to support it. The second option seems unreasonable to me. Of course if the client wants to poll the global queue it can, but that's not its job - the reason Frost handed the request off to FUQID is that Frost doesn't implement a good progress monitor etc. The third option is possible, albeit slightly perverse. In either of the latter two cases, once a global download has completed, it cannot safely be removed by FUQID, because it can't actually finish until the original client has downloaded the data and saved it to disk locally. Additionally, OnCompletion hooks won't necessarily help us because they would run on the server and not on the client; we have to keep the completed download around until the client reconnects and we tell it and it acknowledges the download. The other possibility is that if the client and server are not on the same machine, we simply don't support handoff. In other words, ReturnType cannot be equal to "direct" on the global queue. This has the advantage of being easy to implement... What is best? -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060320/a4c69357/attachment.pgp>
