logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: [change@xxxxxxx: Bug#176282: libxmltv-perl: Add option to run tv_grab_n: msg#00039

Subject: Re: [change@xxxxxxx: Bug#176282: libxmltv-perl: Add option to run tv_grab_na --configure automatically if provider changes]
On Sat, 11 Jan 2003, Kenneth Pronovici wrote:

>I just received this bug report from Debian's BTS.  Would you be
>willing to add the sort of option that Kingsley here suggests?

>>From: change@xxxxxxx
>>Subject: Bug#176282: libxmltv-perl: Add option to run tv_grab_na --configure 
>>automatically if provider changes
>>To: submit@xxxxxxxxxxxxxxx

>>The main reason that I'm writing is to suggest adding
>>an option to tv_grab_na so it's rerun with the 
>>"--configure" option if the provider's number has changed.
>>
>>For example, my provider's number seems to change almost 
>>daily and tv_grab_na was aborting with 
>>
>>      provider:
>>        299950 # <provider's name> 
>>      is no longer valid, choose a new one
>>
>>I've worked around the problem by checking tv_grab_na's 
>>return status and optionally rerunning it with --configure.

The trouble is that when you run a grabber you expect it to produce
listings.  Either that or fail with a message saying why it
cannot.  You probably don't expect it to go off and do other things,
not even configuration.  Think about a program which runs tv_grab_na
noninteractively and waits for the output.

OK, this is not a reason not to add the _option_ of
reconfigure-if-necessary; but it does explain a little why I feel this
behaviour doesn't really fit in.  Doing this stuff in a shell script
is probably the Right Thing.

However, that does raise the question of how to distinguish between
'reconfiguration needed' and other kinds of failure.  Perhaps we
should standardize the exit status of the grabber to 0 for success, 1
for need to reconfigure, ..., 255 for any other error.  Whatever we
choose to do should be the same for all grabbers, not just tv_grab_na,
and that is another reason I'm reluctant to recommend adding the
feature.

I suppose we could add an option, common across all grabbers, to
reconfigure if necessary *and then go back to grabbing
listings*.  That might be useful for other programs calling the
grabber, especially if we ever get around to making the configuration
GUI-based with Tk.  But still I think that just returning a clear exit
status and letting the caller decide would be better.

(If you are forwarding bugs filed against Debian's xmltv packages it's
better to send a message to xmltv-devel rather than to me directly.  
I have cc'd this reply there as well as to Debian's bug tracker.  
Anyone on the list have a different view of this feature request?)

Perhaps if the user change@xxxxxxx could give more details on how he
or she is running the grabber (from the command line? from a shell
script? from some bigger app?) we'd get a clearer idea of the best
answer.

-- 
Ed Avis <ed@xxxxxxxxxxx>







<Prev in Thread] Current Thread [Next in Thread>