| Summary: |
some way to deal with crashed observers |
| Product: |
Telepathy
|
Reporter: |
Simon McVittie <smcv> |
| Component: |
tp-spec | Assignee: |
Senko Rasic <senko.rasic> |
| Status: |
RESOLVED
DUPLICATE
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
normal
|
|
|
| Priority: |
medium
|
|
|
| Version: |
unspecified | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
15:58 < wjt> it'd be useful if an observer could ask MC what channels it *would* have been asked to observe, had it been running when they were opened 15:59 < wjt> because otherwise when you're developing an observer and you restart it, you need to restart all your channels before it notices them 16:00 < sjoerd> being able to get all of the current channels might be good enough for those use-cases though 16:01 < smcv> yeah, like the DispatchOperationList interface 16:01 < smcv> but MC already knows how to match channels against filters, so... 16:01 < sjoerd> yup 16:01 < smcv> it's inherently racy, of course - the observer working out what it ought to be observing races with the handler ack'ing messages 16:02 < smcv> but it might be useful for observers that crash and auto-restart, at least 16:02 < smcv> (in which case you already crashed, so potetially losing a few messages is to be expected) 16:03 < wjt> hell, we could have an RestartMeIfICrash property