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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
