Hi Justin, At Sat, 4 Jun 2011 15:14:29 +0400, Justin Forest wrote: > I think it is a good idea to use an external download manager. Not > only for mobile devices, but in general. So that gPodder would focus > on podcasting and not deal with bandwidth throttling, etc.
Woodchuck isn't so much about performing downloads as it is about scheduling them. That is, Woodchuck's primary goal is to determine when it is a good time to download data and which data to download. (That said, it does provide a simple downloader for objects accessible over http and https.) As gPodder should not depend on Woodchuck (at least not until Woodchuck becomes widely adopted) and as gPodder's download functionality already works, I intend to only hook gPodder up to Woodchuck's scheduling frame work when Woodchuck is available. > My understanding is that there would need to be an API to queue an URL > for downloading, Right. The basic idea is that gPodder registers a stream for each podcast subscription (pywoodchuck.stream_register). At some point, Woodchuck makes an upcall telling gPodder that it is a good time to update one or more streams (pywoodchuck.stream_update_cb). (If gPodder is not running, Woodchuck first starts it using org.freedesktop.DBus.StartServiceByName.) gPodder then updates the feeds and reports whether the update was successful (pywoodchuck.stream_updated). For each new episode, gPodder registers a new object (pywoodchuck.object_register). At some point (perhaps immediately), Woodchuck tells gPodder to download some objects (pywoodchuck.object_download_cb). gPodder then downloads the objects and reports success or the type of failure (pywoodchuck.object_downloaded). When the user listens to a podcast, gPodder reports this to Woodchuck (pywoodchuck.object_used). That way, Woodchuck can learn the user's preferences. If the user wants to listen to a podcast episode and it is not downloaded, gPodder can still download it in the usual fashion. Nevertheless, gPodder should still report that it was downloaded (pywoodchuck.object_downloaded) so that Woodchuck can improve its model of the user's preferences. > get asynchronous updates and pause/cancel specific > file, maybe pop up a settings dialog. I'm not sure what you have in mind here. Could you elaborate? > The rest would be done by an > external module which would use Woodchuck on Maemo, Right. > something else on desktop, There is no reason that Woodchuck cannot also be used on the Desktop. > gPodder would have a local implementation based on download.py, in > case the external module does not exist. Right. I figure that that could be done in a similar way to how gPodder handles DBus when it is missing--an empty implementation. Neal _______________________________________________ gpodder-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-devel
