Summary: | Expose resources | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Jonny Lamb <jonny.lamb> |
Component: | tp-spec | Assignee: | Jonny Lamb <jonny.lamb> |
Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | enhancement | ||
Priority: | low | Keywords: | patch |
Version: | git master | ||
Hardware: | Other | ||
OS: | All | ||
URL: | http://git.collabora.co.uk/?p=user/jonny/telepathy-spec.git;a=shortlog;h=refs/heads/resources | ||
Whiteboard: | review+ as draft | ||
i915 platform: | i915 features: |
Description
Jonny Lamb
2010-07-30 08:17:19 UTC
Simon, I added a ro property to specify whether the resources are human readable as you suggested. So I implemented this in gabble. I missed out client type because that branch hasn't been merged and I wanted to make the branches independent. It'll be easy to add it later. http://git.collabora.co.uk/?p=user/jonny/telepathy-gabble.git;a=shortlog;h=refs/heads/resources Seems to work fine. The spec looks good as a draft.
> + <tp:copyright>Copyright (C) 2010 Collabora Ltd.</tp:copyright>
Nitpicking: s/(C)/©/?
Regarding Gabble: Regression tests are good, and should have caught this: > + if (name == g_quark_from_static_string ("MailNotificationFlags")) > + g_value_set_uint (value, GABBLE_RESOURCES_HUMAN_READABILITY_MAYBE); ^^^^^^^^^^^^^^^^^^^^^ > +static const gchar * > +presence_id_to_status (GabblePresenceId id, > + TpConnectionPresenceType *type) Surely this *must* be duplicating something in conn-presence.c? (It's entirely possible that the information exists in conn-presence.c but needs some refactoring, though.) (Be particularly careful about Senko's new plugin-defined presences, which can be visible on the self-handle (if the self-resource is exposed) and didn't exist when you wrote this branch...) > + val = tp_g_value_slice_new_boxed ( > + GABBLE_HASH_TYPE_RESOURCE_INFORMATION_MAP, resources); [...] > + g_hash_table_unref (resources); Just take_boxed to avoid a copy? Nitpicking: > This is the case in XMPP -- > + most resources are set in a way that the user can deduce some > + information from them, such as <em>this guy is in the > + office</em> or <em>this guy is chilling at home</em> I don't think the ", such as..." adds much to this :-) > absense absence > + XMPP, the resource string could still be useless, like in the > + case of using gtalk where your resource is forced.</p> the resource string could be partially human-readable (as on Google Talk, where a resource of "home" is changed by the server to a unique string like "home_1234fdec") or not at all human-readable. I merged my draft spec, thanks. I'll open another bug about my gabble branch. |
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.