[Kget] cvs location for bittorrent plugin

Dario Massarin nekkar at libero.it
Sun Mar 6 19:28:41 CET 2005


> Currently it is under transfers/bittorrent/ but maybe there will be an
> extra plugin directory where it would fit better?

This directory is perfect :-). All the transfer implementations should be 
always put under the transfers/ directory.


I've just committed some code, although ATM nothing works (read "it's 
broken"). At least in this 
way I can show you my new code. 
I'm afraid I will not be able to work much more on kget in the upcoming weeks. 
So what I propose is a sort of cooperation between us. I don't have enough 
time to rewrite all the KGet code alone and, in the meantime, I don't want 
you guys to wait for my work. 

I think a good division of the work could be:

----- Felix -----
You could work on the transfer classes and implementations. 
You could also work on the Factory (that doesn't exist yet), since you now 
need this in order to make bitTorrent work together with TransferKio.

Factory: 

This should be a class containing a function like:
/**
 * Creates a new transfer pointing to the url "src". In order to do this it 
 * queries all the available plugins
 */
Transfer * createTransfer(  TransferGroup * parent, Scheduler * scheduler,
                                      const KURL & src, const KURL & dest );

In the future we should put also a function providing a detailed widget for 
each transfer implementations, and maybe more others. We should put this in 
core/factory.h core/factory.cpp.

-----Pino -----
Since time ago you proposed to rewrite the old scheduler functions, maybe you 
could be interested in the Model and Scheduler classes. Currently these 
classes are almost completely unimplemented. What do you think?

Discussing with Enrico we thought that the Model class shouldn't contain lots 
of functions as in the previous implementation. It should be able to create 
transfers from xml or from url. 
When creating Transfers from url the Model class should call the Factory 
function createTransfer(...).  Ah, and yes, the Model should be the one who 
creates the Factory and holds a pointer to it.

Note that the introduction of the Model class makes the creation of a 
TransferLoader class (as we discussed earlier) almost useless (since 
TransferLoader and Model would perform the same tasks).

The challenge is to rewrite this code making a really good API (and I believe 
you can be better than me in this :-) )



If you think the division of the work I just proposed sucks, let me know. 
It would be really very exciting to work on kget all together!

Best wishes,
	Dario



More information about the Kget mailing list