[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] GNUNET_PROGRAM* option evaluation does not work

From: Christian Grothoff
Subject: Re: [GNUnet-developers] GNUNET_PROGRAM* option evaluation does not work as expected
Date: Sat, 16 Mar 2019 20:14:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/16/19 9:44 AM, Schanzenbach, Martin wrote:
> Really? I think it is pretty obvious. The gnunet-uri arguments might
> change; the binary itself might be renamed / deleted in the future. 

Unlikely. And if that happens, we can always adjust gnunet-qr.

> This is only detectable through runtime tests, then.

Sure. But a simple comment in the file "gnunet-qr depends on this, be
careful when changing" should suffice to help here.

> And, considering
> that the QR could contain _anything_, error handling (in gnunet-qr)
> is extremely limited and consequently user feedback also.
That's a more serious concern, but given that neither gnunet-uri nor
gnunet-qr do much in terms of error handling today, I'm not sure it is
critical. Error handling here is also tricky, as gnunet-uri is itself
pretty generic and simply re-dispatches execution to URI handlers based
on the configuration.  So it also doesn't have much information to go by
for error handling.

Also, I'm not sure what kind of error handling you have in mind. Sure,
we can (and should) return 0 or non-zero depending on success/failure,
but that's realistically all I'd expect for now. I'm not sure what else
can reasonably be done, or what types of failures you'd want to handle
differently that really changes the user experience.  So in the abstract
your point seems valid, but given what gnunet-uri and gnunet-qr
concretely do, I still don't buy it. Using different exit status values
from gnunet-uri should suffice for all cases I can imagine right now.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]