[systemd-devel] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods

[Tomasz Bursztyka]

Hi Lennart,

>>>>> 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.
> Well, clients have to deal with errors anyway, since they are talking
> to this via dbus. I mean, the service might simply be missing on the
> system, and the client code should then downgrade to DIRECT
> anyway... Hence, the right client side behaviour is to eat up *all*
> error conditions, regardless if they stem from the dbus code, the
> socket calls used by dbus or ultimately from the proxy discovery
> daemon...

Either way is fine to me, the end result will be the same anyway: the client
cannot do anything but trying to connect directly. It will need to be 
clearly
told in the api documentation.

Tomasz