Merge lp:~ben-hutchings/endroid/presence into lp:endroid
Status: | Merged |
---|---|
Approved by: | Martin Morrison |
Approved revision: | 77 |
Merged at revision: | 43 |
Proposed branch: | lp:~ben-hutchings/endroid/presence |
Merge into: | lp:endroid |
Diff against target: |
294 lines (+193/-15) 3 files modified
src/endroid/plugins/broadcast.py (+171/-0) src/endroid/rosterhandler.py (+5/-8) src/endroid/usermanagement.py (+17/-7) |
To merge this branch: | bzr merge lp:~ben-hutchings/endroid/presence |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Morrison | Approve | ||
Review via email: mp+180390@code.launchpad.net |
This proposal supersedes a proposal from 2013-08-09.
Commit message
Rosterhandler pushes up more information about available presences - now storing the priority and status of resources.
The broadcast plugin can be configured to the following levels:
- all: broadcast to all a user's available resources
- positive: broadcast to all a user's available resources with positive (or zero) priorities
- max: broadcast to the user's highest priority resource
- none: do not broadcast (leave it up to the server)
This should allow EnDroid to emulate the most common server behaviours when it comes to sending messages.
Description of the change
Rosterhandler pushes up more information about available presences - now storing the priority and status of resources.
The broadcast plugin can be configured to the following levels:
- all: broadcast to all a user's available resources
- positive: broadcast to all a user's available resources with positive (or zero) priorities
- max: broadcast to the user's highest priority resource
- none: do not broadcast (leave it up to the server)
This should allow EnDroid to emulate the most common server behaviours when it comes to sending messages.
usermanagement and rosterhandler changes are logically nice. However, the implementation is a little too voodoo for my liking. :-)
I think it's as simple as turning _members[userhost] from a set of magic (and error-prone) Resource object into a dictionary of full_jid -> "properties" (which can be as simple as a tuple of (show, priority)). This would make the "updating" look less magic, without any loss of functionality.
In the broadcast plugin, the StringKeys stuff is a little nasty too. You can get the same behaviour with the simpler:
class Level(object):
NONE = "none"
ALL = "all"
POSITIVE = "positive"
MAX = "max"
Which incidentally is also closer to the true enum support that now exists in Python 3.4.