Re: [PATCH Adding proxy settings 1/4] Service API documentation updated to include Proxy settings updates.

2010-10-06 Thread Tomasz Bursztyka

Hi,

On 05/10/10 15:17, ext Marcel Holtmann wrote:

please update your documentation patch and start working on the
implementation. I think just storing it in src/service.c like we do for
domains and nameservers should be good enough. Since essentially ConnMan
is not doing anything with these values at all. So no need to involve
any IP internal here.
   
I started according to that and it fits nicely. I am currently about to 
commit

the manual part now but I have a last question about it:
- Do we manage an ignore list of hosts?

To me, that would make sense to manage it, and again: that's quite easy to
implement in connman, and then we won't have anything to change in proxy 
support
in connman. The only part which will require a bit of work will be 
PACrunner.


What's your opinion with such feature?

Also please update PACrunner to accept the same Servers property with
the manual method. And of course the pacrunner plugin to send these
values.
   

I will prepare PACrunner patches when I am ready with connman part
(which means: connman patches reviewed/proposed/accepted and then commited
upstream).

Best regards,

Tomasz
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH Adding proxy settings 1/4] Service API documentation updated to include Proxy settings updates.

2010-10-05 Thread Tomasz Bursztyka

Hi

On 05/10/10 12:41, ext Marcel Holtmann wrote:

Means that a simple entry like [ server:901 ] would be the generic one
and [ http://server:901;, ftp://server:109; ] could identify different
servers.
   

That seems fine, let's do that way.

Best regards,

Tomasz
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH Adding proxy settings 1/4] Service API documentation updated to include Proxy settings updates.

2010-10-05 Thread Marcel Holtmann
Hi Tomasz,

  Means that a simple entry like [ server:901 ] would be the generic one
  and [ http://server:901;, ftp://server:109; ] could identify different
  servers.
 
 That seems fine, let's do that way.

please update your documentation patch and start working on the
implementation. I think just storing it in src/service.c like we do for
domains and nameservers should be good enough. Since essentially ConnMan
is not doing anything with these values at all. So no need to involve
any IP internal here.

Also please update PACrunner to accept the same Servers property with
the manual method. And of course the pacrunner plugin to send these
values.

Regards

Marcel


___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH Adding proxy settings 1/4] Service API documentation updated to include Proxy settings updates.

2010-10-04 Thread Marcel Holtmann
Hi Tomasz,

  doc/service-api.txt |   65 ++
  1 files changed, 59 insertions(+), 6 deletions(-)
 
 diff --git a/doc/service-api.txt b/doc/service-api.txt
 index c4e1495..87053c2 100644
 --- a/doc/service-api.txt
 +++ b/doc/service-api.txt
 @@ -410,12 +410,65 @@ Properties  string State [readonly]
   If no automatic configuration is available,
   then direct is set.
  
 - The values auto and manual are not yet
 - supported.
 -
   string URL [readonly]
  
 - Automatic proxy configuration URL.
 + Automatic proxy configuration URL. Used when
 + Method is auto-config or auto.
 +
 + string Http [readonly]
 +
 + Address/hostname for HTTP proxy. Used when
 + Method is manual
 +
 + uint16 HttpPort [readonly]
 +
 + Port number for HTTP proxy. Used if Http has
 + a value.
 +
 + string Https [readonly]
 +
 + Address/hostname for HTTPS proxy. Used when
 + Method is manual
 +
 + uint16 HttpsPort [readonly]
 +
 + Port number for HTTPS proxy. Used if Https has
 + a value.
 +
 + string Ftp [readonly]
 +
 + Address/hostname for FTP proxy. Used when
 + Method is manual
 +
 + uint16 FtpPort [readonly]
 +
 + Port number for FTP proxy. Used if Ftp has
 + a value.
 +
 + string Socks [readonly]
 +
 + Address/hostname for socks proxy. Used when
 + Method is manual
 +
 + uint16 SocksPort [readonly]
 +
 + Port number for socks proxy. Used if Socks has
 + a value.
 +
 + string Rtsp [readonly]
 +
 + Address/hostname for RTSP proxy. Used when
 + Method is manual
 +
 + uint16 RtspPort [readonly]
 +
 + Port number for RTSP proxy. Used if Rtsp has
 + a value.
 +
 + array{string} Ignore [readonly]
 +
 + List of networks or hostnames that do not
 + have a proxy.

what is wrong with just using Server, Port, Username and
Password fields here?

Do we really wanna support different proxy servers for different
protocol types? I don't think that is really useful. We wanna make this
as simple as possible for the end users. And expose less settings as
possible.

Regards

Marcel


___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH Adding proxy settings 1/4] Service API documentation updated to include Proxy settings updates.

2010-10-04 Thread Tomasz Bursztyka

Hi,

On 04/10/10 14:44, ext Marcel Holtmann wrote:

what is wrong with just using Server, Port, Username and
Password fields here?

Do we really wanna support different proxy servers for different
protocol types? I don't think that is really useful. We wanna make this
as simple as possible for the end users. And expose less settings as
possible.

   
Why not following what is used everywhere: browsers sets the proxies 
that way, Qt does, and many others too.
I agree that it lacks one thing here: a boolean field that enable 1 
generic proxy url/port for all (then only Http/HttpPort would be useful) or
which selectively enable different protocols. Like it is done in let's 
say: firefox.


About Username/Password, this is quite advanced settings, and then it 
would require to store such pair for every type of proxy. (This is what 
gnome does if I recall well). And it is actually as rare to get an 
access-resticted proxy than a protocol based proxy configuration.


I know it expose then quite much settings, but end-user is not entitled 
to manipulate those on its own. I mean, it is up to UI to expose those.
Isn't so that ConnMan should be able to handle as much settings as it 
could, so that UI would be able to expose in a simple way basic settings 
as well as advanced settings? At least in that particular case: proxies.


And is ipconfig.c the right place anyway?

Best regards,

Tomasz
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH Adding proxy settings 1/4] Service API documentation updated to include Proxy settings updates.

2010-10-04 Thread Marcel Holtmann
Hi Tomasz,

  what is wrong with just using Server, Port, Username and
  Password fields here?
 
  Do we really wanna support different proxy servers for different
  protocol types? I don't think that is really useful. We wanna make this
  as simple as possible for the end users. And expose less settings as
  possible.
 
 
 Why not following what is used everywhere: browsers sets the proxies 
 that way, Qt does, and many others too.
 I agree that it lacks one thing here: a boolean field that enable 1 
 generic proxy url/port for all (then only Http/HttpPort would be useful) or
 which selectively enable different protocols. Like it is done in let's 
 say: firefox.
 
 About Username/Password, this is quite advanced settings, and then it 
 would require to store such pair for every type of proxy. (This is what 
 gnome does if I recall well). And it is actually as rare to get an 
 access-resticted proxy than a protocol based proxy configuration.
 
 I know it expose then quite much settings, but end-user is not entitled 
 to manipulate those on its own. I mean, it is up to UI to expose those.
 Isn't so that ConnMan should be able to handle as much settings as it 
 could, so that UI would be able to expose in a simple way basic settings 
 as well as advanced settings? At least in that particular case: proxies.

actually ConnMan should only expose what we want the user be able to
change. So right now, I would just agree on Server and Port manual
proxy settings and then see how far we get with that. I am fine with
leaving authentication details out for now.

And browser etc. do a lot of things. This doesn't mean they are correct
and it most certainly doesn't mean the user can make sense out of them.
So just adding something with the reason that Mozilla's UI does it right
now is not an argument that I would buy easily.

The more I come to think about this stuff, the more I want just plain
Server and Port properties. If we ever need something more, then we
can just add a list of URIs that would overwrite the default.

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.

Keep in mind that only the configuration of proxies should be done via
ConnMan. The actual request for using a proxy needs to be done via
pacrunner and is FindProxyForURL method. And that one can parse these
nicely apart.

 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.

Regards

Marcel


___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman