[Kget] kuiserver and kget2 issues

[John Tapsell]

Rafael,

  I realise you don't want to be confrontational, but it does seem to
make sense if kuiserver does replace kget entirely.

  I don't think it makes sense to have a torrent kioslave, however as
kuiserver could support showing ktorrent's downloads, and ktorrent can
already run minimised and auto run when you click a torrent, I think
no more is needed.

  As for multithreaded stuff - I don't understand why so I'll leave
that to others.

JohnFlux

On 04/02/07, Rafael Fernández López <ereslibre at gmail.com> wrote:
> Hi KGet team (and KDE community),
>
> I'm the kuiserver developer (well, the one that rewrote it). I see necessary
> that we talk about kuiserver and kget2 !! So many people have told me we are
> going in somehow in the same direction, and that our work could be merged
> (or something) somehow.
>
> The kuiserver point is to have a KJob inherited class, and with the right
> signals and calls to the Observer class, the kuiserver is notified through
> dbus about that data, and shown. A big amount of different data can be
> shown, which file, from where (or device), to where (or mountpoint), the
> progress, the speed, an info message... that sort of things.
>
> It allows you to add what right now are called "capabilities". I added some
> functionality to KJob that lets you add it capabilities (Pausable,
> Killable...), and then, the kuiserver will show buttons for those actions.
> Those actions list can be extended for new needs, of course. So by now, on
> download/copy jobs, you can pause/resume it, or cancel it.
>
> I really know KGet2 has some other interesting features. Like multithreaded
> downloads, torrent support and so on.
>
> Some people have suggested me to merge KGet2 and kuiserver. Well, I want to
> place my point of view of all this: kuiserver goal is not to give
> multithreaded downloads, or torrent support. No. And notifying the user
> about a file local copy operation (for example) is not a KGet2 goal. So, the
> question here is: what we can do.
>
> 1) kuiserver allows to inform about downloads, and whatever you can imagine
> that inherits KJob, and iteract with them with the capabilities support.
> 2) KGet lets you interact with downloads, and will give nice support like
> multithreading downloads, mirroring search, torrent support...
>
> I always have wondered (and suggested sometimes on k-c-d) why we hadn't  the
> possibility of queueing downloading jobs on konqueror (or in kde in
> general). It is possible on kget.
>
> Well, I haven't talked to David or Kevin what they think about this, and
> probably I'm totally wrong, in that case, just correct me :). From my point
> of view, KGet2 has *VERY INTERESTING* features, but nothing that can't be
> added to kdelibs (or somewhere else). If we could give multithreading
> downloads to KIO::Job, what would you say ? Great !!. That's the point.
> Torrent support can be handled in many ways, like writing a KIO::slave, so
> we could give Konqueror the capability of that too (in addittion to
> multithreading downloads in kio::jobs, for example), or the power to queue
> jobs natively (no with an "external" app).
>
> Now what I really want to point out is that I'm not against KGet2 in *ANY*
> way. I find it important to know what the KGet2 developers team think about
> all this, and act, always thinking of a better KDE desktop, that is for what
> we are all here. My goal is not to kill KGet2 as it can seem at a first
> view, I repeat it.
>
> Obviously, waiting for comments. :)
>
> Thank you and bye,
> Rafael Fernández López.
>