#7740 NORM 8.2.0 (: react gracefully to dbus services being restarted

[Zarro Boogs per Child]

#7740: react gracefully to dbus services being restarted
----------------------+-----------------------------------------------------
   Reporter:  mtd     |       Owner:  mtd                 
       Type:  defect  |      Status:  new                 
   Priority:  normal  |   Milestone:  8.2.0 (was Update.2)
  Component:  sugar   |     Version:  Git as of bug date  
 Resolution:          |    Keywords:  8.2.0:? r-          
Next_action:  code    |    Verified:  0                   
  Blockedby:          |    Blocking:  6995, 7690          
----------------------+-----------------------------------------------------

Comment(by mtd):

 Replying to [comment:3 marco]:
 > Did you check that all the services you are changing are stateless (or
 cleanup themself correctly)?

 Yes, I checked that.  I worry that you're asking because you know of some
 subtle gotcha I've missed, but all three things I changed seem obviously
 stateless:

 - nmclient.NMClient._nm_obj is only used to setActiveDevice() - the rest
 of the code already follows name changes via a signal and doesn't care
 about that member variable

 - battery.py is obviously stateless - just reading and displaying a value;
 the only thing remotely stateful is to get notified when the dbus proxy's
 properties change in an interesting which, in which case we definitely
 want to follow name changes (as you can see by my test case, this is not
 happening now)

 - keyhandler.py's speech object is obviously stateless -- the dbus lookup
 is just cached for tidyness, it seems.

  Here is a good explanation of how the follow_name property should be
 used:
 >
 > http://dev.laptop.org/ticket/2773#comment:11

 Thanks.  I read that and it was consistent with everything I'd read at:

 http://dbus.freedesktop.org/doc/dbus-tutorial.html#bus-names

 http://lists.freedesktop.org/archives/dbus/2006-September/005559.html

 http://log.ometer.com/2007-05.html

 > I'm not convinced about the _dbus_safe thing. It seem too generic (and
 despite that it's only private). What about a _get_battery_property()
 which takes a default value, and logs something like "Failed to get
 battery property...".

 I can reduce the diff to one line if you want.  The rest is just tidy up.
 "too generic" - you mean the decorator name "_dbus_safe" is too generic?
 I can add a _get_battery_property function that does exactly the same as
 the decorator, but the decorator seems cleaner to me and accomplishes
 exactly the same thing (and is almost exactly what decorators were used
 for).  Would you be alright if I changed the name of the decorator to one
 of:

 _dbus_unwind_protect
 _catch_dbus_errors_with

 ...or something similar?

 I don't want this cleanup/change to detract from the patch, so if you're
 uneasy, I will a patch without the cleanup.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7740#comment:4>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system