Some protocols (AIM, Yahoo, and possibly others) allow you to be online from your mobile phone or hiptop or something, and communicate this to your buddies. Pidgin et al. can then display a mobile symbol beside such people in your buddy list. Various protocols also have status metadata like user mood, user tune, and geolocation. All these could be exposed on the same interface, presumably providing a method :: Handle → a{sv} or similar. It might also make sense to expose idleness in the same way, although on some protocols it is a boolean and on others a time.
(This was triggered by http://bugzilla.gnome.org/show_bug.cgi?id=547658 )
Having a "mobile" bit of metadata would be handy, so Empathy could just treat those users as offline. :-P (I think I've gotten about a 1% response rate from mobile IM users; a few didn't seem to realize their phone had IM capability (though obviously they configured it at some point). maybe general behavior has changed since I last tried it) But, seriously, it would be nice to know if someone is mobile. I believe there was a draft for a geo-location spec, but I can't seem to find it. I've suggested the idle idea before, and the consensus seemed to be that it should be implemented in the clients. Though maybe, if some protocols support it, it would be nice to be able to get clients' idle times upon first connection of the account (and then do the book-keeping locally after that)?
We should have one interface per broad feature. Connection.Interface.Location is in draft. Connection.Interface.Mood, C.I.Music and C.I.Mobility (?) could be added too. Let's use this bug to represent mobileness and clone it for the others.
ya we deff. need a fix for this i talk to people all the time that are mobile so i would like to know if they are mobile or not.
Not that I have a lot of friends connected to XMPP using their phone (yeah N900! :), that's really an information that I'd like to know.
Note: Gabble 0.8.10 and 0.9.4 will have a new configure argument, --enable-is-a-phone, which will allow Gabble packages for mobile devices (like the N900) to report their nature. But Gabble still doesn't expose that information. Reassigning to the -bugs list.
In XMPP the closest equivalent actually seems to be the list of Service Discovery Identities <http://xmpp.org/registrar/disco-categories.html#client>: clients can have one or more identity, chosen from bot, console, handheld, pc, phone, web (where console means a tty, rather than a gaming console :-) It might be better to expose (the list of|one of) these identities, rather than just a boolean flag. I suspect other protocols can be mapped into this namespace.
(In reply to comment #7) > In XMPP the closest equivalent actually seems to be the list of Service > Discovery Identities <http://xmpp.org/registrar/disco-categories.html#client>: > clients can have one or more identity, chosen from bot, console, handheld, pc, > phone, web (where console means a tty, rather than a gaming console :-) > > It might be better to expose (the list of|one of) these identities, rather than > just a boolean flag. I suspect other protocols can be mapped into this > namespace. That sounds like a good idea to me. Several protocols distinguish between the normal graphical client, web messenger, and mobile at least. I was also wondering if it would be useful to add to that list specifically a phone number opposed to say a client running on a phone. Such as you can add a phone number "contact" that you can send SMSes to (Yahoo and MSN can both do this), but the contact isn't using an IM client of any shape or form. They just send and receive normal SMS messages.
*** Bug 29149 has been marked as a duplicate of this bug. ***
> /client-type — a{sv} (Location) Um... no. Copypasta detected! It's probably worth mentioning explicitly that "console" means a text-only interface, and doesn't mean a games device :-) (the rest are pretty obvious without having to refer to the Registrar). If we're going to specify here that the most available presence is used, SimplePresence should also say so. It's probably worth saying explicitly that the Client_Type is the type of the client whose SimplePresence we see. In the intro docstring, there are some <p> that contain a <ul>. You can't do that in HTML (<p> is "smaller than" <ul>), so close the first <p> before the <ul> and reopen it after.
(In reply to comment #10) > Um... no. Copypasta detected! Okay, now that I know you're on the ball, I can take your review seriously. You passed the first test and I congratulate you on this. (I.e. fixed) > It's probably worth mentioning explicitly that "console" means a text-only > interface, and doesn't mean a games device :-) (the rest are pretty obvious > without having to refer to the Registrar). Okay, I guess so. I was deliberately leaving out descriptions and leaving them up to the registrar webpage but I guess this one makes sense. Done. > If we're going to specify here that the most available presence is used, > SimplePresence should also say so. It's probably worth saying explicitly that > the Client_Type is the type of the client whose SimplePresence we see. Okay. I didn't update SimplePresence; I'd like to keep these separate so I'll do it in another branch. I've updated this interface though. > In the intro docstring, there are some <p> that contain a <ul>. You can't do > that in HTML (<p> is "smaller than" <ul>), so close the first <p> before the > <ul> and reopen it after. Hm, okay, done. I just changed the branch name to match reality, so look here instead for updates: http://people.freedesktop.org/~jonny/telepathy-spec-client_type/spec/Connection_Interface_Client_Type.html
More updates: 1. I changed "client type" to "client types", so now the interface returns a list of client types, not just a single string. The UI can decide what to do with >1 types. 2. I added an "sms" client type for Mike's point about SMS contacts. hth
(In reply to comment #12) > 1. I changed "client type" to "client types", so now the interface > returns a list of client types, not just a single string. The UI > can decide what to do with >1 types. Relatedly, should I change this to Conn.I.ClientTypes then?
(In reply to comment #13) > Relatedly, should I change this to Conn.I.ClientTypes then? Yes please. Other errata I'd like to see in the first merged version: * add 'game' or 'gaming-device' or something (MSN would map the XBOX flag to this, and in principle there could be a Playstation or Wii XMPP client) * talk to the XMPP Registrar about getting 'game' and 'sms' added to the registry - if they're useful for us, they're useful for other people Things that can be deferred for later: * Jonny thinks the ClientTypes interface should be defined to give the client types of the resource visible via SimplePresence; I wonder whether it should be the union of all resources. Open question, doesn't need to be answered for a draft. * Some way to set your own client type(s), other than by hard-coding them like Gabble currently does. I think it should be a connection manager parameter whose name is well-known - perhaps even a DBus_Property. * Perhaps it would be appropriate to put software name and version, if known (in XMPP it is), in this interface?
(In reply to comment #14) > * add 'game' or 'gaming-device' or something (MSN would map the XBOX flag to > this, and in principle there could be a Playstation or Wii XMPP client) Done. > * talk to the XMPP Registrar about getting 'game' and 'sms' added to the > registry - if they're useful for us, they're useful for other people I'll do that now. 'ere you go then. Branch updated, and new HTML uploaded. What do you think? http://people.freedesktop.org/~jonny/telepathy-spec-client_types/spec/Connection_Interface_Client_Types.html
(In reply to comment #15) > 'ere you go then. Branch updated, and new HTML uploaded. What do you think? I like it; please merge as a draft. Non-blocking changes: I wonder whether we should introduce a Client_Type tp:simple-type to list the well-known client type strings.
(Merged => not on the review queue.)
Merged for 0.21.1.
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.