Some client methods have an a{sv} for things we haven't yet thought of. Others do not.
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.
Proposal: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/asv-all-round
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.