Hi Alan, Alan Maguire wrote: > hi folks > > I've been looking at implementing the event notification mechanism for phase > 1, where interested clients such as the GUI apps and the commandline UIs > register for notification of events of interest from nwamd (e.g. got an IP > address, switched NCPs etc). The current code utilizes doors as the backend > IPC mechanism between clients and the daemon, but while this approach is > good for the single-client case, it's more complex as we scale up to more > clients (the daemon has to keep track of these multiple clients and hold > onto notifications for events that occurred at time N until all clients > registered before time N have been notified or have gone away.
Understood... > > It seems to me that sysevents might be a good fit for dealing with this > problem - i.e. the client (via libnwam) binds and registers for > NWAM-specific sysevents pertaining to autoconfiguration state. One problem > with this - I believe there's a bug in that sysevent_[un]bind_handle() > requires a uid of 0 to complete successfully (the right fix here, I think, > is to add privs and auths to add to the console user profile so it can bind > and receive sysevents). Otherwise, I think we'd end up reinventing a similar > mechanism. What do people think? Is this a reasonable approach? (I'd > estimate it'd take about a week to implement this). Thanks! This sounds fine - the main thing for us (the clients) is that the actual mechanism isn't exposed - which I believe is what you're suggesting. >From my (admittedly poor) understanding of sysevents, they are quite "sparse" in that they don't contain a lot of information, so I would presume that we would receive an event, and then, should we need more information (e.g. Scanned Wlans) we would make a call via libnwam which is likely to use doors to get the information. Is that correct? Or would it be more likely that this would happen under the cover in libnwam itself, and when an event is dispatched to the client it would already contain this information? I suppose what I'm really asking is how exactly this change effects the UI, since it's really an implementation detail that shouldn't cause impact on the UI's use of the libnwam APIs... >From what I've seen in the commit messages, you seem to have fixed the requirement of a uid of 0 - so that should remove any related issue on the UI side as long as the necessary auth is in the default set for Network Autoconf... Thanks, Darren.
