Re: NM dialup API

[Will Stephenson <wstephenson kde org>]

On Thursday 19 April 2007 13:58:34 Dan Williams wrote:
> On Thu, 2007-04-19 at 13:18 +0300, Tambet Ingo wrote:
> > On 4/19/07, Will Stephenson <wstephenson kde org> wrote:
> > > Is anyone working on turning this into a dbus spec yet?  I can help
> > > with this if needed.
>
> The D-Bus spec for the API that info-daemons (the things that pass
> system-wide and user-scoped configuration to NetworkManager) is pretty
> much spec'ed out, but comments are certainly welcome and appreciated.  I
> sent a mail to the list back in Feb. that layed out my thoughts on the
> NM <-> info-daemon API.
>

I've reviewed the February thread and had a think about it.  Summarising my 
reading of it:

*) Less state is to be made available to the client to prevent cross-session 
information leakage.

*) Instead the active (according to ConsoleKit) settings service is queried 
for policy or notifies when policy changes

Questions:
In a{sa{sv}}, what does the middle 'a' mean?  Does the first string key 
eg 'ip4-settings' point to an array of dicts containing those settings, and 
not a single dict?  
Or is that first 's' the identifier of the Connection?  In that case what's 
the outer array for?
Comments:
I'm seeing question marks about what policy is visible to clients.

*) System-wide configured wireless, vpn, dialup connections should be visible 
to clients so that they may control them.  Connections added by other clients 
should not.  

*) a{sa{sv}} dismays me because it's such a low level lump of data. Is the 
revised interface on NM for discovering the available devices and connections 
going to be similarly barren?  I was expecting it would be richer and more 
object oriented than the 0.6.x interface.  If one call supplies all the 
settings data to the daemon from a settings service for all of the 
connections, this could be a large amount of data if the user has accumulated 
a lot of wireless network settings, so it could take time to marshal.

*) Given a tightly defined set of settings groups and the values available in 
them, we could use to define an OO dbus interface on NM to determine Devices, 
their Connections and the Settings groups on them depending on their type.  
This would be easier for client app authors to target.

Will