On Fri, 2013-02-15 at 12:23 +0200, Jukka Rissanen wrote:
> Hi Tomasz,
>
> On 15.02.2013 10:49, Tomasz Bursztyka wrote:
> > Hi Jukka,
> >
> >> enum {
> >> - USER_ROUTES_CHANGED = 0x01,
> >> + USER_ROUTES_CHANGED = 0x01,
> >> SERVER_ROUTES_CHANGED = 0x02,
> >> + TYPE_CHANGED = 0x04,
> >> + NAME_CHANGED = 0x08,
> >> + HOST_CHANGED = 0x10,
> >> + DOMAIN_CHANGED = 0x20,
> >> + SETTINGS_CHANGED = 0x40,
> >> };
> >
> > VPN_PROVIDER_ as a prefix for all the keys maybe?
>
> I am not sure about that one, I like the shorter version ;)
> The enums are local to the file anyway.
>
> Patrik, what is the verdict :)
I think the code should call provider_property_changed() directly for
all the independent properties at least. It seems that also the existing
USER_ROUTES_CHANGED can be updated immediately. The only two places
where get_user_networks() is called to fetch new values is in
set_property() where the old value will be removed and
__vpn_provider_create() where a new value is created. In any case an
equal number of property change messages are sent over D-Bus with no
difference whether 100ms is waited or whether the update is sent
immediately.
For SERVER_ROUTES_CHANGED it seems that the server can push new routes
at will, but appending new ones to already existing ones must be handled
by the code already. Thus the question is whether those server route
updates almost always come in many separate messages from the external
vpn application to create the need for having extra code waiting 100ms
before sending updates. It seems we could take the simpler code path
here also by sending a property change each and every time a server
route is appended, but I don't know what the average number of server
routes per vpn is in real life. Any ideas/number of routes?
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
