> On 15. Mar 2019, at 22:51, Christian Grothoff <[email protected]> wrote: > > On 3/15/19 4:06 PM, Schanzenbach, Martin wrote: >> No it was not. >> I am pretty sure that instead of calling gnunet-uri as a binary from a >> binary is pretty nonsensical. > > Why? I see nothing wrong with that. It's not like this matters for > performance or that starting gnunet-uri has any other real disadvantage > here that I can think of.
Really? I think it is pretty obvious. The gnunet-uri arguments might change; the binary itself might be renamed / deleted in the future. This is only detectable through runtime tests, then. And, considering that the QR could contain _anything_, error handling (in gnunet-qr) is extremely limited and consequently user feedback also. > >> Instead, gnunet-qr should just do what gnunet-uri does with the uri. >> If we need to share code between them, fine, then refactor. But imitating >> python behavior here is not good style. >> Hence the CLI tools should be built using GNUNET_PROGRAM_run (). > > Ok, now I undestand why you suggested GNUNET_PROGRAM_run(), but I don't > see this as "Python" behavior, more like UNIX behavior ;-). > >>> On 15. Mar 2019, at 06:10, Christian Grothoff <[email protected]> >>> wrote: >>> >>> Signed PGP part >>> On 3/13/19 6:25 PM, Hartmut Goebel wrote: >>>> Martin wrote: >>>>> The first thing you should do it use GNUNET_PROGRAM*. >>> >>> Actually, that advice was slightly off: as you don't want/need the >>> scheduler, you don't need GNUNET_PROGRAM_run() but just GNUNET_GETOPT_* >>> for gnunet-qr. >>> >>> >>> >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
