[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