Hi,
On 04/10/10 17:47, ext Marcel Holtmann wrote:
Meaning a list of "socks://xxx:901 ftp://yyy:222"; is a perfect
description of proxies. And that is a lot easier to configure than
having to have separate properties for different protocol types.
Why not doing it that way now? This seems indeed the smartest way:
- easy to implement (in connman side at least)
- answers all cases (protocol specific, login/pass, port ...)
- and definitive as a solution (if we first implement this Server/Port
thing, and then move to this uri way: it will mean an API change,
and usually it's preferable to avoid such change.)
Then we could have such Service API description for proxies:
--------
dict Proxy [readonly]
string Method [readonly]
Possible values are "direct", "auto",
"manual" and "auto-config".
If the DHCP server provides an automatic
configuration URL, then this value is set
to "auto-config". The PAC file will be
referenced by the URL value.
If no automatic configuration is available,
then "direct" is set.
string URL [readonly]
Automatic proxy configuration URL. Used by
"auto" and "auto-config" methods.
array{string} URI [readonly]
List of proxy URIs for specific protocols.
Used by "manual" method.
If "auto" is set without an URL then ConnMan
will try to retrieve it through WPAD protocol.
dict Proxy.Configuration [readwrite]
Same values as Proxy property. The Proxy represents
the actual system configuration while this allows
user configuration.
All methods are supported but "auto-config"
(which might be set if DHCP is in use).
--------
I took care of your idea about "auto" method. However, in next patch I will
probably split it so that it first implements the manual thing (URI) and
then
the auto method (wpad or not). One thing at a time.
And is ipconfig.c the right place anyway?
Right now it seems sensible since we have all the other proxy details in
there as well. However it comes of course together with the service
structure. And especially we need access to it via service functions do
make sure we load this into pacrunner.
Or we could do: all "common" part to service.c (method, dbus api, key
file storage, ...),
only the auto-config pac stuff will stay in ipconfig.c. In fact, while
going through
dbus api for the service, we should know if auto-config is in use or not
according to
the value of "pac" attribute in ipconfig structure. To me this makes
more sense that way,
since proxy config if much more about "service" rather than "ip
configuration", only
auto-config part is indeed close to ip since it is set through dhcp.
What do you think?
Best regards,
Tomasz
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
