#2783 NORM Untriag: Public API should deal with service crashes

[Zarro Boogs per Child]

#2783: Public API should deal with service crashes
--------------------+-------------------------------------------------------
 Reporter:  marco   |       Owner:  dcbw     
     Type:  defect  |      Status:  new      
 Priority:  normal  |   Milestone:  Untriaged
Component:  sugar   |     Version:           
 Keywords:          |    Verified:  0        
--------------------+-------------------------------------------------------
 Split from #2773. I'd say this is FRS work.


 By smcv:

 No, calls will fail after the service crashes or is stopped. If you add
 follow_name_owner_changes=True to the get_object() call, it *might* work,
 or not - it depends entirely on the D-Bus interface you're wrapping.
 That's why the dbus-python default is to not follow owner changes.

 This can only be fixed on a case-by-case basis, by someone who understands
 the API that's being wrapped.

 If the API you're wrapping is stateless, using follow_name_owner_changes
 will work.

 If you want to cope with crashes in a stateful API, you probably have to
 expose more of the detail of what's going on to the API user. For
 instance, invalidating objects when the service that created them crashes.


 By Tomeu:


 The clipboard service is not stateless, we keep in-memory references to
 the clipboard objects.

 The bundle registry is stateless, as it just scans the bundle dirs at
 startup.

 The object registry is also stateless.

 The services in the shell process are not stateless.

 I'm not sure about the presenceservice, but I guess it's not stateless
 (gives references to objects that won't exist after a service restart).

-- 
Ticket URL: <https://dev.laptop.org/ticket/2783>
One Laptop Per Child <http://laptop.org/>