<div>On 7/20/07, Jussi Kukkonen <<a href="mailto:jhkukkon@cc.hut.fi">jhkukkon@cc.hut.fi</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> keith preston wrote: > There was a part in the api specification for shutting down backend > services.   We could call that method, although it doesn't quite work if > others are listening.    There could be a shutdown signal broadcast to > inform users that a backend is going down an a stop shutdown method.   I'm > open to other ideas.   Or we could just ignore this because if it gets > shutdown and someone else makes a dbus call to it, it will restart. I like the shutting_down-signal idea. At least it's the best solution I can think of. So the plan is this: 1. Add functions to C library       geoclue_*_shutdown_specific(service, path);    I can't imagine where a default version  (like with init) would be    needed... but geoclue_*_shutdown_all() might be useful.</blockquote><div> I do like the idea of geoclue_*_shutdown_all to be a geoclue master api.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2. Add signals to backend interface (and corresponding callback-setters    in C library):       <signal name="shutting_down">       geoclue_position_set_shutdown_callback()    How does the dbus stuff work: do the receivers know which backend    sends shutting_down-signal (in case there are several running) or    should that info be included as an argument?</blockquote><div> Yes, the receivers should know who sends the signal.   To hear the signal the receivers must specifically subscribe to a signal from dbus.   So when a reciever connects to a backend, it will also connect to it's shutdown signal.  Keith </div></div>