Summary: | Decide where a{sv}s are needed for future expansion of clients | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
Component: | tp-spec | Assignee: | Simon McVittie <smcv> |
Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | normal | ||
Priority: | medium | Keywords: | patch |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
URL: | http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/asv-all-round | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 21148, 21256 |
Description
Simon McVittie
2009-04-14 08:25:36 UTC
Possible places we might want an a{sv} for future expansion: * Observer.ObserveChannels: we already have Observer_Info * Approver.AddDispatchOperation: if we turn the expansion things into immutable properties of the channel dispatch operation, then we're fine; the only problem is if their values can change, in which case either we use an InitialFoo hack (and don't allow the value to change until ADO has returned so the client has time to connect to signals), or the client calls back to the dispatch operation to get the initial value just after connecting to signals. Neither is a huge burden, so I don't think an a{sv} is necessarily needed. * Handler.HandleChannels: we don't have a Handler_Info but IMO we should add one * Handler.Interface.RequestNotification.AddRequest: we pass in exactly the request and its immutable properties, which we can always add to later; same considerations as A.ADO above. Relatedly, ChannelRequest doesn't have an Interfaces property; for future expansion, perhaps it should. If so, MC should pass it in all the usual dicts of immutable properties. Approved by Rob and Sjoerd with their spec cabal hats on Was fixed in 0.17.23 |
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.