| Summary: | rethink RoomList interface | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | enhancement | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Simon McVittie
2007-11-22 06:56:23 UTC
Documentation accompanying the "requestotron" spec (request use-cases req9 and req10) explains how we plan to do this. While thinking about requestotron design issues, we've come up with the following suggestions: * we should change the API so RoomList is not a singleton and each RoomList has exactly one user * on protocols where we can list rooms in a parallelizable way (XMPP) we should just do so * on protocols where the room list is maintained in memory at all times (Clique) RoomList channels should be views onto it * on protocols where room listing is not parallelizable and involves being flooded with data (IRC) we should either have the second RoomList channel not actually start listing until the first has finished, or even cache the list from the first channel and replay it in the second Fixed several spec releases ago, and even implemented in Gabble. |
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.