Hi Tomasz,
> > 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.)
I am actually thinking that I want both. One "Server" + "Port" for the
generic proxy server that we use if nothing else has been specified.
And then allow a list of URIs to give specific ones. Reason here is that
I am actually seeing that the generic one is the one that should be used
at all times. However giving users the chance to deal with crazy
sysadmins not doing it properly.
Then the UI can pick and choose what the offer the user. And on the
ConnMan side we are not cluttering our APIs with it.
> 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.
So this should be better be named "ServerURIs" or something like that.
However when I am thinking about now, a simpler "Servers" string array
might be work as well.
Means that a simple entry like [ "server:901" ] would be the generic one
and [ "http://server:901";, "ftp://server:109"; ] could identify different
servers.
> 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.
actually auto is not close DHCP. Only a few DHCP servers give you the
PAC URL. Most likely it will be discovered via WPAD.
And since WPAD is a blunt layer violation on all sides anyway, it could
be open on how we do it. However since we wanna store the manual proxy
configuration or manual PAC URL for auto configuration, we should better
put this into the src/service.c.
Regards
Marcel
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
