Hi Dan, > > 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 the reason why I am for example not using the property standard in BlueZ is because dbus-glib is the most braindead implementation of it all. If I have additional signals or methods for the same interface I would like to use the properties for, I have to actually create two proxy objects. That is just not worth it. I know that dbus-glib nicely allows to use its GObject based property system to export D-Bus properties, but it fails to add support to the proxy objects to actually get/set remote properties. And parsing introspection XML for getting the result of readonly or readwrite is kinda overkill :) Regards Marcel