kuiserver and kget2 issues

[Urs Wolfer]

On Sunday 04 February 2007, Rafael Fernández López 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.

Thanks for starting this discussion!

> 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 like the new kuiserver.

> I really know KGet2 has some other interesting features. Like multithreaded
> downloads, torrent support and so on.

A list of some already implemented / planed features of the new KGet:
* Multithreaded downloads (even over different protocols at the same time -> 
useful for e.g. metalink)
* Plugin based architecture (easy way to support new transfer protocols 
(emule, torrent, ...))
* Mirror search of downloads
* Metalink support (http://metalinker.org)
* Bandwidth limits

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

That should be available also without KGet. These is a basic function.

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

IMHO it is nice if kuiserver supports _basic_ file operations, like download a 
file, pause a download, etc.
But: Do you think it would be a good idea to integrate a full downloadmanager 
into kdelibs / kdebase? Does a *normal* user need multithreaded downloads? 
IMHO no. If we integrate everthing that could be nice into kdelibs / kdebase, 
we can drop the other modules. A download manager with features more than 
just start / pause / stop a download belongs into kdenetwork.

Of course KGet will / should support the kuiserver! It should show the 
progress of each download or all downloads together.

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

This is the opinion of two of the three KGet main developers (Manolo Valdes' 
and my own. Manolo wrote his mail just to the kget ml.) Dario, the third KGet 
developer, has at the moment no internet connection. We have to wait for his 
thoughts...

Bye
urs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070205/9f0f7fc8/attachment.sig>
-------------- next part --------------
_______________________________________________
Kget mailing list
Kget at kde.org
https://mail.kde.org/mailman/listinfo/kget