<div><span class="gmail_quote">2007/2/5, Michael Pyne <<a href="mailto:michael.pyne@kdemail.net">michael.pyne@kdemail.net</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Sunday 04 February 2007 17:55, John Tapsell wrote:<br>> I don't think it makes sense to have a torrent kioslave
<br><br>It makes no sense at all. :)</blockquote>
<div> </div>
<div>Well, yes... but we are in the same case. KUIServer should show every progress of every job, or at least an info message of what's going on. Now, the transfer of a torrent can be paused or canceled (mainly), and that can be done with the kuiserver only. So we have KTorrent, KGet for the same thing. And KUIServer *POTENTIALLY* can do the same, but with every kind of jobs, not only for downloading torrent files, and not only for downloading files, but for showing any kind of job.
</div>
<div> </div>
<div>As you know kuiserver won't talk to any protocol at all. It just receives signals and shows the data wherever needed. It can add support for actions, for adding buttons, but results on a slot called on the KJob inherited class, so that signal can be treated specifically.
</div>
<div> </div>
<div>The thing here, is that we have something like:</div>
<div> </div>
<div>KTorrent < KGet < (potentially, not true right now) KUIServer + something</div>
<div> </div>
<div>That "something" is "the thing" that talks to each protocol, creates a KJob inherited class and updates the kuiserver with the progress of the download (a torrent or whatever file we want). In order to have the full capabilities of KGet, "the thing" should be able to multithread downloads, queue them, and so on.
</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Regards,<br>- Michael Pyne</blockquote>
<div> </div>
<div>Bye,<br>Rafael Fernández López. </div></div>