English > Feature Suggestions

Split information gathering and user interaction...

<< < (3/3)

raldo:

--- Quote from: rick.ca on July 22, 2009, 09:59:48 am ---If this were simply a matter of deferring necessary user interaction to the end of the batch, with no deferral of the download once an ambiguity is resolved by the user, I wouldn't be too concerned about such things. But I still have questions. How would the program handle error conditions?
[...]
I really don't think this would be appropriate for large batches. I doesn't make sense to run an overnight update of 500 with the idea the user will be willing and able to resolve an interminable number of ambiguities in the morning.

--- End quote ---

Yeah, well, I'm sure there are some issues that I haven't thought of but I, and I am sure many others, would very much want such functionality.

rick.ca:
I sure everyone is in favour of complete, trouble-free updates with a minimum of user-interaction. I don't think we're likely to get any closer to that goal—unless all the relevant issues are properly considered.

I wonder if a "unified" approach might be feasible. By that, I mean one update routine that adapts itself to whatever the circumstances. Based on what we've discussed so far, it might be naturally "silent" by deferring items needing user interaction to the end of the batch. It's unclear to me, however, how different error conditions can be properly identified and then handled in the most productive manner (i.e., abort batch, skip item, or defer and ask user at end?). Once the routine is in "interactive mode," should the user be asked (once an ambiguity or whatever has been resolved) whether to download now, queue download, skip, abort, etc.? Maybe there just needs to be one dialog at the end of the first pass. Something like, "x items cannot be processed without your input... Proceed, Quit, Bookmark and quit?"

raldo:
I don't really know, because I haven't seen errors like these...

What about some kind of error log?
Edit:
Errors resulting from http problems (server glitches, file no longer exists, record no longer exists) -> error log?
Option to bookmark unresolved items vs. disambiguation dialogs -> seems like a good idea.

rick.ca:
Not being able to make errors happen, I have to rely on my faulty memory on what kind of errors can occur and their frequency. Maybe all possible errors can be cleanly divided into two types—those that should result in the routine being aborted (e.g., site not accessible), and those that should result in the item being deferred for another attempt, user input, or error reporting. But I wonder about errors that might fit both definitions. For example, if every 10th item fails, it would make sense to defer those items At worst, the routine will be 90% successful. But what if the very same error happens with every record? I suppose that possibility might be taken care by something like aborting after three consecutive errors, rather than the first of any particular type.

Everything is logged if the program is run with the -debug switch. In some cases, I suppose it would be helpful to present captured error messages in the user interaction stage. At the end of the routine, it might be handy to see a list of items not updated (which might be due to error, or the user's choice to skip rather than disambigulate), along with an option to bookmark these items for follow-up.

Another complication in this is the fact plugin/scripts can be run in batches. I suppose this idea would have to applied to each source separately. Problems resolved with the first source may avoid problems with subsequent sources.

Navigation

[0] Message Index

[*] Previous page