Bug 17219

Created attachment 18403 [details] [review]
patch to enable priority-{away,available}

This is the corrected patch from the maemo bug mentioned by Alberto.

*** Bug 18225 has been marked as a duplicate of this bug. ***

Altering priority at all (once per connection to the server, as an account preference) is already supported in Gabble, but not in Maemo's UI (a UI designer decision), so that bit is NOTOURBUG. The fact that the default is 0 might not be very appropriate, though, since that's the lowest priority you can have without triggering the special negative-priority ("don't send me messages") handling in the server.

Altering priority at runtime in response to presence statuses (as in Maemo#2141) is a reasonable feature request, but why do only "available" and "away" get special treatment? Should the other presences we support ("busy", "xa" and "chat") etc. get the available priority, the away priority, a hard-coded priority or something else? Discuss.

My inclination would be that "busy", "available" and "chat" should all set the higher priority (even if you're busy, the device you're busy on is still the one you're primarily using), "away" sets a lower priority, and "xa" is either the same as "away", or even lower. The old "priority" parameter should probably be used for the highest of the priorities (with a suitably increased default), and the new priority-away parameter should perhaps default to half of priority or something in order to get sensible behaviour if priority takes a non-default value.

(The Maemo UI can't set "chat" or "xa", but sets "busy" if invisible is selected but not supported by the server. Empathy can't currently set "chat", but can set "busy", and automatically sets "xa" after you are away for a while.)

Having the same values of priority that Pidgin does as the defaults seems sane.

Setting as enhancement.

I'm a bit skeptical of adding a plethora of connection parameters for the priority of each resource. I think that, if anything, Gabble should use the 'priority' param when Available, and a value between 0 and 'priority' for other statuses, according to the same scale as other clients.

(Priorities are pretty crap, because if you use two clients with different scales, you lose unless you go through manually tweaking them all, which no user should have to do.)

Pidgin uses a priority of 1 for Available, and 0 for everything else. I can't see any way to change these from the UI, although it's technically possible to make a custom status with a different priority. A first step might be to change Gabble's default to 1, and do the same scaling (for very binary values of "scale") as Pidgin does. What do Gajim, Psi, etc. do?

(In reply to comment #5)
> I'm a bit skeptical of adding a plethora of connection parameters for the
> priority of each resource.

One reason is that, once added, it's hard to remove connection parameters without breaking everyone's accounts.

(In reply to comment #5)

> (Priorities are pretty crap, because if you use two clients with different
> scales, you lose unless you go through manually tweaking them all, which no
> user should have to do.)

Clients having hardcoded scales are pretty crap. I am using quite a few computers with carefully crafted priority/statuses scale. For me this limitation is a show-stopper. I've been using gajim on linux, audium (pidgin-based) on mac os x and patched gabble on maemo. Now I considered gabble for linux again and it still doesn't support status-dependent priority :-( For me (and I believe I'm not the only one) this is very important feature.

I think I should find some time for another attempt on the patch. Simon made some valid points here that I should take into account. And, Simon, to answer your question why away and available deserve special treatment - because I had literally 20 minutes to get it done. I actually originally meant the patch to serve a better explanation of what is really needed... And because I've been doing the patch for maemo version. Of course it should be done better for a full-blown client...

Not sure why it didn't make it onto this bug, but Rob suggested a while ago that the ideal thing would be for Gabble to adjust its priority automatically, rather than needing explicit configuration or hard-coded priority numbers, with these goals:

A. Gabble's priority is >= 0 (so we get messages at all)

B. Gabble's priority is lower than the priorities of any resources with
   a presence that is "more available" than Gabble's

C. Gabble's priority is higher than the priorities of any resources with
   a presence that is "less available" than Gabble's

D. If it isn't possible to satisfy A, B and C simultaneously, work out
   which is most important (I would guess A > B > C)

(for some definition of "more available": perhaps a very simple one, (chatty == available) > (away == busy == xa), or perhaps something more complicated.)

I seem to remember Google Talk has, or had, a good algorithm for that?

For that to happen, someone who uses multiple resources will need to write a patch, and more importantly, justify why it's correct.

If someone wants to write a comprehensive patch for the simpler "offer some configurable priorities" version, I wouldn't say no to that, but it will have to cover all the statuses (perhaps just by dividing them into broad categories, "available/chatty" and "away/busy") and have sensible defaults.

I'm sure the current "our priority is always the same" approach is pretty bad for many use-cases, but it's at least easy to understand/describe :-)

Also interesting:

http://blog.jdconley.com/2007/05/xmpp-presence-priority.html
http://mail.jabber.org/pipermail/standards/2007-May/015189.html

but that approach has been questioned: it might be better to just try to have the same priority on all resources, and hope that the server sends new messages to all joint-highest-priority resources:

http://mail.jabber.org/pipermail/standards/2007-May/015276.html

Additionally, "message carbons" are a better long-term solution - they do require server support, but I'd welcome an implementation for Gabble:

http://xmpp.org/extensions/xep-0280.html

Will's comments above are also recommended reading.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/11.