Hello, ext George Wright wrote: [...] > The idea of this project is to allow clients to be written to > a standard API and not have them tied down to any one single > implementation of Mission Control.
Nice, this was really needed. > So far I have made the following decisions: [...] All of those seem fine to me. > SetPresence ( u: presence ) -> nothing Since Telepathy API allows setting and retrieving presence+message with a single call, I think we'd better do the same in mission-control. > SetEnabled ( b: enabled ) -> nothing [...] > IsEnabled ( ) -> b Small remark about naming: [Get|Set]Enabled, or [Enable|IsEnabled] seem more consistent. > - Abstract plugins like Decibel's "Component" system. These are like > Nokia Mission Control's channel handlers and filters. We need to come > up with a standard API for these. Is Decibel using components only for handling channels as Nokia MC does, or do they something more? > - Accounts; enabled, normalised name, display name, etc - do we want to > implement these as D-Bus properties or methods? I'll leave the decision to someone more expert about D-Bus. :-) > - We need something like Nokia Mission Control's "Profiles" system > because changing a connection manager for a given protocol isn't > necessarily going to work as there is no exhaustive standard > for the configuration settings a given connection manager should > take. Particularly, we need to decide on who provides the profiles; > Mission Control, the UI or somewhere else? This has also some impact on the accounts API: AddAccount (which I would rather call CreateAccount) needs to receive the profile in input. About account creation, Nokia MC does not emit the "AccountCreated" signal until the account is complete (i.e., all the required parameters are set), because it's likely that clients listening to this signal would respond to it trying to get some information on the newly created account, or put it online. Maybe we could split the API into two different parts: CreateAccount ( [s:profile?] ) -> o That creates the account object but doesn't return it in ListAccounts and friends, and maybe emits an AccountCreated signal (but would it be of any use?), and AddAccount ( o:account ) -> nothing that will register the account to the AccountManager and emits the AccountAdded signal. So, for creating an account one would call CreateAccount(), set all the needed properties/parameters, and then call AddAccount(). In the ProtocolManager (or, probably better, in a separate Protocol class) we need a method for retrieving the list of the valid protocol parameters, with their type, default value and whether they are required. Also, some way to link the bits together, that is from Account get the Profile, and from the Profile the Protocol. About your last question, on who should provide the profiles, I wouldn't be so concerned about that: they could be provided by the connection manager, if it is so specific that the profile can be shipped together with it (for instance, ICQ, Yahoo and MSN won't probably need more than one profile), or by some third party (every SIP service would probably want to provide a profile). Ciao, Alberto -- http://www.mardy.it <-- Geek in un lingua international! _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
