[Kget] Fwd: Re: idea about content fetching plugin

[Lukas Appelhans]

Next forward of my reply
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: [Kget] idea about content fetching plugin
Datum: Freitag, 28. März 2008
Von: Lukas Appelhans <l.appelhans at gmx.de>
An: "Ningyu Shi" <shiningyu at gmail.com>

Am Donnerstag, 27. März 2008 21:25:52 schrieben Sie:
> 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.
Mmh, probably make the download not to start per default... not sure...
>
> >  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:))
Yes, but for changing the download-threads we should have a GUI-Config 
provided by the MultiSegKio plugin. Anyway we should add a QWidget * 
transferConfiguration(); which gets inserted into TransferSettingsDialog...

Regards

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



-------------------------------------------------------