On Thu, 2008-12-11 at 08:41 -0800, Dirk Brandewie wrote: > Hi Everyone, > > The attached files represent a proposed dbus based API to access the > Linux WiMax stack. This proposal is the result of a number of > discussions over the last few months at OLS and the plumbers > conference. > > Overview: > There are two object types used to access the WiMax stack the adapter > and network object. > > The adapter (adapter-api.txt) object is created when the hardware > device is discovered in the system. This object is used to control the > state of the adapter and the process of scanning for available > networks. > > The network (network-api.txt) object is created when a network is > discovered via the adapter.Scan() method. This object is used to > control the state and report information about available network > connections. > > There is one helper agent (agent-api.txt) that is meant to call out to > gather user credentials i.e.(username, password). The current file is > just a placeholder. > > Comments and suggestions gratefully accepted. One general comment before I go through it in more detail. The methods dealing with Properties are redundant, since there's a standard D-Bus interface specification for object properties. Check out: http://dbus.freedesktop.org/doc/dbus-specification.html and look for the "org.freedesktop.DBus.Properties" section. I'll copy it here since it's so short: ------------------------------------------------------- org.freedesktop.DBus.Properties Many native APIs will have a concept of object properties or attributes. These can be exposed via the org.freedesktop.DBus.Properties interface. org.freedesktop.DBus.Properties.Get (in STRING interface_name, in STRING property_name, out VARIANT value); org.freedesktop.DBus.Properties.Set (in STRING interface_name, in STRING property_name, in VARIANT value); org.freedesktop.DBus.Properties.GetAll (in STRING interface_name, out DICT<STRING,VARIANT> props); The available properties and whether they are writable can be determined by calling org.freedesktop.DBus.Introspectable.Introspect, see the section called ?org.freedesktop.DBus.Introspectable?. An empty string may be provided for the interface name; in this case, if there are multiple properties on an object with the same name, the results are undefined (picking one by according to an arbitrary deterministic rule, or returning an error, are the reasonable possibilities). ------------------------------------------------------- There isn't yet a PropertiesChanged signal, but that's something that we should all standardize on, and just add to the D-Bus specification. It's been discussed upstream before, but nobody has quite gotten around to proposing it. I need it for NetworkManager, David Zeuthen needs it for HAL/DeviceKit, and it's generally useful. So lets just standardize a PropertiesChanged signal format, and I'll take the task of getting it into the D-Bus spec. Note that none of the calls/signals on this interface require changes to D-Bus, they are implemented in the services and clients that use D-Bus as the IPC mechanism, and thus will work on all existing systems. Dan
