[Kget] kget BIG next changes

[Urs Wolfer]

Hi

On Sunday 07 January 2007 21:36, Dario Massarin wrote: 
[..]
> 1) make it possible for a Transfer to implement or not some interfaces we
> provide, for example a) Container (still looking for a better name..)

Probably TransferUnit? But TransferContainer doesn't sound bad at all!

> b) Segment
> c) BandwidthControl (in the future..)
> d) ...
[..]
> 4) The gui would automatically display for each plugin the transfers, where
> available, that belong to a certain container transfer. This means that,
> for example, in a Metalink download we could automatically see all the
> "segments" we are downloading, despite they are http, ftp, torrents, etc.

I think something like the KTorrent transfer detail would be nice.

> With this in place, in order to potentially fully support Metalink (which
> is kind of hard, as you can see ;-) ), it will be able enough just to build
> one container Transfer that will transparently query kget for the existence
> of plugins that handle the list of urls Metalink gives. If no torrent
> plugin is there, we will not use it, but it would be sufficient to add a
> bittorrent plugin (or a eDonkey one) to use it, without any more troubles
> and changes in kget core code.

That sounds great!

[..]
> What do you think?

I like your idea! It sounds very promising. KGet is going to be a KILLER app 
for KDE4!

> (I don't know how much time I'll have to work on this, but maybe it's not
> really so hard as it seems..)

In the next time I hope to have a bit more time to work on KGet. Next thing 
I'll do is cleanup and improve the whole action-stuff in KGet (I have to wait 
for the big change in kdelibs, which will probably happen tomorrow).

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/kget/attachments/20070107/ece02fe3/attachment.pgp