[Kget] kuiserver and kget2 issues

[Manolo Valdes]

El Domingo 04 Febrero 2007 6:20 PM, Rafael Fernández López escribió:
> Hi KGet team (and KDE community),
Hola Rafael

kget2 is hoping to handle all sort of download manager tasks like:

bit torrents
multithreaded
metalinkers
bandwithd limits
mirrors searching 
and so on

i guest kioserver now have the ability to action on the kjob plus its old task 
of showing it.

i already sow the screenshots of kioserker. it looks really great.

so i guest we can work around to use kioserver to also show kget current jobs.
And maybe the endusers want to use kget capabilities through kioserver or not.

what do you think Dario? Urs?

let me know yours point of view

Saludos
Manolito

>
> 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.