[Kget] Fwd: idea about content fetching plugin

[Ningyu Shi]

forget to reply to maillist
---------- Forwarded message ----------
From: Ningyu Shi <shiningyu at gmail.com>
Date: Thu, Mar 27, 2008 at 11:25 PM
Subject: Re: [Kget] idea about content fetching plugin
To: Lukas Appelhans <l.appelhans at gmx.de>



On Fri, Mar 28, 2008 at 7:00 AM, Lukas Appelhans <l.appelhans at gmx.de> wrote:
 > Am Donnerstag, 27. März 2008 20:54:27 schrieb Ningyu Shi:
 >
 > > Hi everybody,
 >  >
 >  > I've read some tutorial of Kross and find it really powerful. Here is
 >  > my rough idea of the content fetching plugin.
 >  Cool :)
 >
 > >
 >  > I'll create a dummy transfer plugin which takes the URL and the kind
 >  > of user script to use. Then the url and transfergroup info and the
 >  > script to use will be exposed to user through kcross. The script will
 >  > run through kross on a seperate thread which will not block the main
 >  > program (The fetching script may take a long time to analyze stuff and
 >  > have multiple URLs to output).  we can ask the user use the dbus
 >  > interface to add download to specific group. To be able to control
 >  > parameters like how many threads to be used for a single download
 >  > session, we need add more options to the dbus interface. But if we do
 >  > this way, the way to add downloads with various options will be
 >  > determined by the script not the users which will be a problem. A
 >  > possible solution is to let the dbus interface only collect the urls
 >  > but not really add them right now, then ask the user to determine the
 >  > way the downloads should be treated.
 >  >
 >  > I'm not sure the above idea will work for the current transfer-plugin
 >  > API, since I've no idea about it now... Any comments/suggestions are
 >  > welcome.
 >  Mmh I'm perhaps a bit tired, but will try to answer:
 >  I would do it mostly as you, but:
 >  -we should know what script is for what website to accept downloads of
 >  contents
 this one is not hard, we can let the user choose themselves. An
 automatical way is also doable, ask the script to provide a function
 of certain name to do that, then we will call these functions one by
 one for all registered scripts to determine which one is suitable. If
 multiple choises rise, let the user decide.

>  -for the content we should use another existing transfer-plugin, so if we have
 >  parsed the script output, we would do KGet::addTransfer(url, dest);
 I've been thinking this for some time. I still prefer to let the user
 call some function or dbus interface to start a download. Because
 there maybe a lot of stuff to download within a content fetching
 session. If we just ask the script to output urls, we have to wait for
 the script to spit the urls one by one and actually monitor it. But if
 we let the user call the addTransfer themselves, they will be able to
 add a download once they got an url out. This issue still needs
 polishing.

>
 >  The threads per downloads are controlled by the multisegkio plugin then...
 yes, I'll try to add plugin based options available to each group and
 each download session. Coz I think it's pretty common to change the
 default download threads when u start a download (at least I do it a
 lot:))

>
 >  Regards
 >  >
 >  > Regards
 >
 >
 >  _______________________________________________
 >  Kget mailing list
 >  Kget at kde.org
 >  https://mail.kde.org/mailman/listinfo/kget
 >



 --
 Ningyu



-- 
Ningyu