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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
