GNOME Bugzilla – Bug 653269
Export extra metadata for Chat
Last modified: 2013-10-27 16:43:46 UTC
Which would be necessary to auto-configure IM accounts. See also: http://thread.gmane.org/gmane.comp.freedesktop.telepathy/5260
So, if I understand things correctly atm switching the 'Chat' GtkSwitch in GOA only add/remove the org.gnome.OnlineAccounts.Chat interface on the account D-Bus object. So Empathy's mission-control plugin (bug #652543) should just check if this interface is present and enable/disable the Telepathy account accordingly. Is that right? What's the best way to know if this interface is there (and be notified) when it's added/removed ? I didn't find any API in libgoa to do that.
Looks like I can do that using the account-changed signal and goa_object_peek_chat().
(In reply to comment #1) > So, if I understand things correctly atm switching the 'Chat' GtkSwitch in GOA > only add/remove the org.gnome.OnlineAccounts.Chat interface on the account > D-Bus object. Yup. > So Empathy's mission-control plugin (bug #652543) should just check if this > interface is present and enable/disable the Telepathy account accordingly. Is > that right? What's the best way to know if this interface is there (and be > notified) when it's added/removed ? I didn't find any API in libgoa to do that. (In reply to comment #2) > Looks like I can do that using the account-changed signal and > goa_object_peek_chat(). Monitoring the :chat property (connecting to e.g. notify::chat) is the preferred way to do this.
(In reply to comment #0) > Which would be necessary to auto-configure IM accounts. See also: > http://thread.gmane.org/gmane.comp.freedesktop.telepathy/5260 Mission control needs to store some extra variable parameters (mostly for cache): HasBeenOnline, Nickname, NormalizedName, AvatarMime, avatar_token, etc. We have 3 options: a) Have a property for each of those on the Chat interface. b) Hae a mission-control-parameters a{sv} property on the Chat interface where we store these things. c) Store them in a specific key file. a) won't really scale if MC needs more properties in the future and I'm not fan of splitting info to 2 different places. Would b) work for you?
It's tempting to make GOA store information on behalf of applications... but after thinking a bit about it and discussing it with mbarnes (for Evolution's use of GOA) we came to the conclusion it is not really desirable. It's much easier if you just store (and delete.. and migrate ... and so on) this kind of information yourself. GOA already gives you an identifier that can be used as the unique key - see http://people.freedesktop.org/~david/gnome-online-accounts-3.1.0/gdbus-org.gnome.OnlineAccounts.Account.html#gdbus-property-org-gnome-OnlineAccounts-Account.Id Here is some more information about how it's supposed to work http://people.freedesktop.org/~david/gnome-online-accounts-3.1.0/overview-writing.html
Ok then I think we don't need any extra metadata.
Reopening that. Even though we don't _need_ the extra metadata to do this (even if just for Google), it would be nice to have so that we can extend GOA without needing to change mission-control. I've removed the blocker status for empathy though.
What do you mean? All the integration (including saving the extra parameters) is done in the MC plugin, no MC changes is needed.
(In reply to comment #8) > What do you mean? All the integration (including saving the extra parameters) > is done in the MC plugin, no MC changes is needed. You need to make changes to the MC plugin for every type of service we would add to GOA, don't you? Just like we currently export "IMAP server" information for mail, we could export "Jabber server" information so that the MC plugin gets support for those services straight away, witjout requiring extra changes. For example, if I added support for "Bastie.net" to GOA, and exported the Jabber server information, the MC plugin would have support for chat straight away, even though I didn't add explicit support for the service.
(In reply to comment #9) > You need to make changes to the MC plugin for every type of service we would > add to GOA, don't you? Right. > Just like we currently export "IMAP server" information for mail, we could > export "Jabber server" information so that the MC plugin gets support for those > services straight away, witjout requiring extra changes. > > For example, if I added support for "Bastie.net" to GOA, and exported the > Jabber server information, the MC plugin would have support for chat straight > away, even though I didn't add explicit support for the service. I see. Are we planning to allow 3rd party to ship their own service?
(In reply to comment #10) > I see. Are we planning to allow 3rd party to ship their own service? No, but it would be nice to minimise the amount of changes necessary to get things integrated.
Ok, so the plan is expose in GOA a set of well known properties and catch them in Empathy's MC plugin to craft the TP account ( 'B' in https://bugzilla.gnome.org/show_bug.cgi?id=661117#c3 ). Is that right? Assuming it is, we'd need: - connection-manager ('s'): 'gabble', 'haze', etc. - protocol ('s') : 'xmpp', 'sip', etc - icon ('s') : 'im-jabber', 'im-msn', etc. - (Optional): Service ('s') - extra parameters (a{sv}) containing any protocol specific param.
Bastien: David: what do you think about this proposal? I'd like to see this in 3.4 and would be happy to implement it.
Created attachment 202597 [details] [review] add properties on org.gnome.OnlineAccounts.Chat This should allow to configure any Telepathy account using GOA.
Humm something is unclear to me. What 'provider' should I pass when creating an account to test this? I didn't find any kind of dummy provider for such generic account.
Created attachment 210356 [details] [review] Export extra metadata for Chat Guillaume said that he won't have time to work on it, so I am finishing what he started. Basically, the objective is to avoid putting Telepathy-isms into the properties to keep them as generic as possible.
I'm not convinced that's the right approach. Why pretending to be Telepathy-agnostic while we are not going to support another IM framework anyway? By doing this GOA won't be able to expose any arbitrary protocol (like SIP for example).
*** This bug has been marked as a duplicate of bug 696267 ***