[Telepathy] MissionControl's spec

Xavier Claessens xclaesse at gmail.com
Wed Oct 24 11:14:42 PDT 2007


I updated telepathy-spec-mc branch [1] and the html spec [2]. I think all
problems mentionned here are more or less fixed now.

Remaining things:

1) I should add {Get|Set}IconName{Updated} to the Account interface?
2) If no presets are provided, who decides DisplayName/IconName?
3) ConnectionManager interface needs Capability management [3].
4) In Chandler file spec, one .chandler file can handle many channel types,
but there is only one TypeSpecificCapabilities field. We need one capability
field per channel type, or only allow one channel type per file.
5) We should set possible errors for each calls
6) Write more comprenhensible doc with better English...
7) Reviewing!

Xavier Claessens.

[1] http://projects.collabora.co.uk/~monkey/telepathy-spec-mc/
[2] http://projects.collabora.co.uk/~xclaesse/spec.html
[3] http://projects.collabora.co.uk/~monkey/telepathy-spec-rob-roundup/

2007/10/21, Xavier Claessens <xclaesse at gmail.com>:
>
> Hi,
>
> I opened a darcs branch to add MissionControl's spec into
> telepathy-spec[1]. You can see generated html [2] I'm not sure it's the
> right place but if I make a separate package I have to duplicate all
> generator code from tp-spec... Also, will we add MC interfaces to
> tp-glib? Maybe in a libtelepathy-glib-mc.so? Like that we can use the
> same code generator to implement MC.
>
> Problems I see:
>
> 1) org.freedesktop.Telepathy.MissionControl.ProtocolManager: Is that
> interface useful at all? libtelepathy already has code to do such
> things. I think we should think about a good profile system instead.
> Information in NMC profiles:
>
>    Manager=gabble
>    Protocol=jabber
>    DisplayName=Google Talk
>    IconName = empathy-proto-google-talk
>    ConfigurationUI = jabber
>    Capabilities = chat-p2p, chat-room, chat-room-list, voice-p2p,
>                   split-account, supports-avatars, supports-alias
>    SupportedPresences = offline,available,away,extended-away,
>                         do-not-disturb
>    VCardField = X-Jabber
>    DefaultAccountDomain = gmail.com
>    Default-$param = $value
>
> - DisplayName: Should be internationalized.
> - IconName: Depends on who install the icon PNGs
> - ConfigurationUI: In N800 that's a string with the path to the UI
> plugin to configure parameters of the account, that totally depends on
> the client. For Empathy it's just a string to choose between available
> hard-coded UIs.
> - Default-$param = $value: That depends on client's policy, for example
> should we ignore ssl errors to connect gmail accounts? It could also be
> set by SIP providers to configure everything for their service.
>
> So who should install profiles? If each client install his set of
> profiles and the user install kopette and Empathy, he will have 2
> profiles for gabble... If the CM install profile how could we have
> translated fields, icons, etc? I don't know how to do that right.
>
> 2) ListAccounts, FindAccounts and GetOnlineAccounts does the same thing:
> finding accounts corresponding to some criterias. ListAccounts can be
> done using FindAccounts(NULL) and GetOnlineAccounts can be done using
> FindAccounts(["status", connected]).
>
> 3) AccountStatusChanged is on AccountManager and GetConnectionStatus is
> on Account... They should be both on the same object, but which one?
>
> 4) ConnectAll: is that useful? The default presence is not defined in
> the spec... I think it can be easily replaced by SetGlobalPresence. Or
> maybe we should define in the spec that MC must save presence for all
> accounts and calling ConnectAll will restore saved presence? In that
> case ConnectAll could be renamed to ResorePresence?
>
> 5) RequestChannel: description says "putting the account online if
> necessary". Ok but with which presence? I think that method should just
> return an error NOT_CONNECTED in that case.
>
> 6) AccountStatusChanged: It gives the account's presence, is that
> useful? We have a signal for presence update on the account.
>
> 7) RequestChannel: handle_type should be u.
>
> That's all for now, I will update my branch with your suggestions.
>
> Xavier Claessens.
>
> [1] http://projects.collabora.co.uk/~monkey/telepathy-spec-mc/
> [2] http://projects.collabora.co.uk/~xclaesse/spec.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/telepathy/attachments/20071024/94ee1b56/attachment.html 


More information about the Telepathy mailing list