This is perfectly OK. How else were you going to do it? Even if you had a long-running plugin, every time it got invoked it would still report each enclosure as "still downloading" or "download complete".
Perhaps I need to clarify: I wrote this with the intention that "all the action" be performed by a single, standard channel plug-in. The plug-in would look through my Awasu Logs directory and determine what enclosures were available to download by examining the RSS in the .xml files. It would then proceed to download those new enclosures that match plug-in parameters: max size enclosure to download, and types to include and exclude. It would download what it could, reporting download success/failure for each via RSS.
The only thing different about this plug-in and, say, my plug-in that monitors the Windows Event Log is how long each runs: grabbing data from the Event Log is fast enough that that plug-in completes in a "normal" time; downloading data over the Internet is much slower. Both plug-ins would gather data (one locally, one remotely) and both would report their results via RSS. I suggested a "special like DownloadUrl" variable, e.g., PluginTimeout, to allow the user to let Awasu know a particular plug-in needed more wall-clock time to complete (to avoid using the "global" Awasu channel timeout setting just to handle a special case).
I was planning on setting the channel to update once or twice per day. In this particular instance, "long running" is much less than 12 hours per day.
In fact, so far the typical daily enclosure list might take 20-45 minutes to download.
Awasu would start the plug-in normally and it would be expected to run to completion. PluginTimeout would be set by the user to either 0 for no elapsed-time limit or a value in seconds; 3600 would obviously give it an hour, after which Awasu would shut it down if it hadn't finished.
A plugin is invoked to *retrieve* the latest information from a given data source. Having a framework to manage processes that *do* the actual work being monitored is beyond the scope of what Awasu is about. What you are suggesting is in fact a cron framework
Yes; exactly what I intended. Since you are building in enclosure support right now, my current plug-in toy isn't really necessary, but I built it precisely to retrieve the latest information (the enclosures) and report its (long running!) activities via RSS.
Having said/written the above, you can obviously take whatever path you deem appropriate for Awasu. I am still able to get everything done I need -- sometimes using Awasu, sometimes not.