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

[Schanzenbach, Martin]

> On 15. Mar 2019, at 22:51, Christian Grothoff <address@hidden> 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 <address@hidden> 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