Closed Bug 954406 Opened 7 years ago Closed 7 years ago

Mark GTalk users on Android as "mobile"

Categories

(Chat Core :: XMPP, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: clokep, Assigned: florian)

Details

Attachments

(1 file)

*** Original post on bio 972 at 2011-08-17 18:49:00 UTC ***

XMPP doesn't seem to have a mobile status, but it should be possible to tell if a user is mobile based on their resource (i.e. if it starts with android, they're most likely mobile). This would be good information to show to the user (and also place the account at a lower priority than other accounts).

Unfortunately this is kind of a hack on the protocol and we would (possibly) need a list of patterns to match again for mobiles (i.e. android, BlackBerry, etc. etc.).
*** Original post on bio 972 by Donnie Muurdock <dgmurdockiii AT gmail.com> at 2011-08-20 21:53:27 UTC ***

http://xmpp.org/xmpp-protocols/rfcs/


The Google Talk client for Android does not include the appropriate XMPP client and is not recognized as a mobile device by multiple XMPP clients, such as Pidgin, Adium, and Digsby.  The client field should include "handheld" or "phone" to advertise that the Talk software is running on a phone and not a PC.  This is useful for other IM users to moderate their IM usage and expectations when communicating with someone on a phone


The string "android" is included in the "status" field, but string-matching should not be used for identifying client types.  Presumably the various official Google Talk clients use this to display the Android icon instead of the standard dots.  Instead, the XMPP client field should be correctly filled out.


Relevant URLs:

XMPP client field documentation:  http://xmpp.org/registrar/disco-categories.html#client

Pidgin bug report for mobile status icons for Android users, marked as won't fix because of XMPP client field missing:  http://developer.pidgin.im/ticket/11761
*** Original post on bio 972 by Donnie Muurdock <dgmurdockiii AT gmail.com> at 2011-08-20 22:26:48 UTC ***

here is some more info i found on this issuse check out this site 

http://www.deepdarc.com/2008/02/14/mobile-xmpp/
*** Original post on bio 972 by Donnie Muurdock <dgmurdockiii AT gmail.com> at 2011-08-21 13:07:53 UTC ***

XMPP on Mobile Devices - http://xmpp.org/extensions/xep-0286.html
Component: General → XMPP
Attached patch PatchSplinter Review
*** Original post on bio 972 as attmnt 2619 at 2013-07-20 21:45:00 UTC ***

My android devices and/or the gtalk servers haven't been very cooperative tonight so I haven't been able to test this patch as much as I would like, but I've seen the mobile icon on one contact (who was connected only from Android) so I guess the patch is fine.
Attachment #8354388 - Flags: review?(clokep)
Assignee: nobody → florian
*** Original post on bio 972 at 2013-07-21 05:18:44 UTC ***

I'm mostly ok with this patch, but a couple questions:
1. My first reaction was that this shouldn't be in xmpp.jsm, but gtalk.js (would that even be possible?), but I guess it actually does make sense since GTalk is currently federated?
2. How do we feel about a random constant in the code, should it be at the top of the file?
3. At [1], mobile is less available than idle, assuming the numbering is important, but this new code block will prefer putting a mobile status over idle. Is this on purpose?

Thanks for looking at this!

[1] http://lxr.instantbird.org/instantbird/source/chat/components/public/imIStatusInfo.idl#16
Status: NEW → ASSIGNED
*** Original post on bio 972 at 2013-07-21 06:30:57 UTC ***

(In reply to comment #5)
> I'm mostly ok with this patch, but a couple questions:
> 1. My first reaction was that this shouldn't be in xmpp.jsm, but gtalk.js
> (would that even be possible?), but I guess it actually does make sense since
> GTalk is currently federated?

I wondered the same thing, but gtalk.js currently doesn't customize/override the prplIAccountBuddy implementation, and doing it just for this seemed overkill, as there would be very little value (it may even be negative value, due to the fact that some people may use gtalk from an 'xmpp' account).

It would make me feel better about the generic accounts if we also supported service discovery and took into account the client category (http://xmpp.org/registrar/disco-categories.html#client).
I don't think setting the mobile status is worth bothering with service discovery (a relatively complicated process) though.

I think we will really want to implement service discovery when we will want to know if a contact can receive files, or a webrtc call.

> 2. How do we feel about a random constant in the code, should it be at the top
> of the file?

When it's used only once and not related to other consts, I feel that keeping the const close to the code using it makes the code more readable.

> 3. At [1], mobile is less available than idle, assuming the numbering is
> important, but this new code block will prefer putting a mobile status over
> idle. Is this on purpose?

Numbering is important. This is on purpose in the XMPP code, as all XMPP resources will also be available, away or idle (all statuses that are more available than "mobile"); ie. if we don't to this, 'mobile' will _never_ be shown.

Whether it makes more sense to prefer talking to a buddy that's "mobile" or a buddy that's idle on a non-mobile device... it's a difficult problem and I suspect the answer is context dependant (depends on how long the user has been idle, and on how much you care about interrupting your contact, or care about the contact seeing your message eventually on a computer from which he can do something about what you are asking...).
Comment on attachment 8354388 [details] [diff] [review]
Patch

*** Original change on bio 972 attmnt 2619 at 2013-07-21 11:54:07 UTC ***

(In reply to comment #6)
> It would make me feel better about the generic accounts if we also supported
> service discovery and took into account the client category
> (http://xmpp.org/registrar/disco-categories.html#client).
> I don't think setting the mobile status is worth bothering with service
> discovery (a relatively complicated process) though.
> 
> I think we will really want to implement service discovery when we will want to
> know if a contact can receive files, or a webrtc call.
Let's keep this in mind and improve this when we implement that.

> > 3. At [1], mobile is less available than idle, assuming the numbering is
> > important, but this new code block will prefer putting a mobile status over
> > idle. Is this on purpose?
> 
> Numbering is important. This is on purpose in the XMPP code, as all XMPP
> resources will also be available, away or idle (all statuses that are more
> available than "mobile"); ie. if we don't to this, 'mobile' will _never_ be
> shown.
I didn't take resources into account, I was just thinking of accounts. It seems like there's no good answer, but the current code looks good for my use cases.
Attachment #8354388 - Flags: review?(clokep) → review+
*** Original post on bio 972 at 2013-07-21 13:25:02 UTC ***

http://hg.instantbird.org/instantbird/rev/bdf1519f19ff
Severity: normal → enhancement
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.5
You need to log in before you can comment on or make changes to this bug.