[systemd-devel] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods
Marcel Holtmann
marcel at holtmann.org
Sun Apr 12 12:53:10 PDT 2015
Hi Lennart,
>>>> +
>>>> +static int method_find_proxy(sd_bus *bus, sd_bus_message *message, void *userdata, sd_bus_error *error) {
>>>> + _cleanup_free_ char *p = strdup("DIRECT");
>>>
>>> Please don't mix variable declarations and function invocations in one
>>> line (also see CODING_STYLE). Also, missing OOM check...
>>>
>>>> + Manager *m = userdata;
>>>> + int r;
>>>> +
>>>> + assert(bus);
>>>> + assert(message);
>>>> + assert(m);
>>>> +
>>>> + r = proxy_execute(m->default_proxies, message);
>>>> + if (r < 0)
>>>> + sd_bus_reply_method_return(message, "s", p);
>>>
>>> Hmm, is this right? Shouldn't we return the error code to the client
>>> instead of eating up and returning "DIRECT"?
>>>
>>> Also, why allocate "DIRECT" with strdup() at all?
>>
>> There are no errors. Either you get a proxy directive or you return
>> DIRECT to indicate no proxy. What would you do in an error case
>> anyway. The backup is always assume no proxy.
>
> Well, so far it has been our coding styles to propagate errors up if
> they cause the invoked operations to fail, and allow the higher up
> code deal with them and possibly eat them up. I mean, the HTTP client
> can eat the error up and downgrade to DIRECT on its own, there's no
> need to do this from our side already.
of course it can, but it also does not help you at all. You are not making anything better here.
I think that one clean interface to this needs to be a API compatible libproxy. Similar to what we did in PACrunner since that allows existing application to just use systemd-proxydiscoverd.
Regards
Marcel
More information about the systemd-devel
mailing list