I am investigating how to use the presence messages provided by the server to indicate granting or revoking of voice in a chat room or to provide additional information such as reason and status when user is kicked or banned. So far it appears to me that incoming Presence messages are not fully deserialized … i.e. the nested <item … /> element in the presence message which contains things like the user’s role, affiliation, and nested reason, status, etc. elements is never deserialized. Am I missing something? Without this it is impossible to notify a user that they have had their voice revoked or the reason they were kicked or banned from the room. Thoughts? Opinions? Anything?
My mistake this time, I think. I was missing a call to super.deserialize() which eventually led to processing the nested elements. I think there may also be an issue with the Flex debugger … a nested array which SHOULD have something in it shows as empty in the inspector in the debugger. Still trying to get this working, but I don’t think my original diagnosis is accurate. More to come …
It looks like it is working properly. False alarm this time. However, I am not quite certain how to handle granting and revoking of voice in a room. For kicked and banned users, the server is kind enough to set a status code of 301 or 307 in the MUCUserExtension so you can tell the user was just kicked or banned. However, for granting or revoking of voice you merely get a presence message with a user item containing the role and affiliation. Since you can get other presence messages with this in them, automatically assuming that a role of visitor implies voice was revoked and role of participant implies voice was granted would probably result in lots of unnecessary messages to the user (saying voice was granted or revoked). It appears that the client has to remember what the user’s current role in order to know if a change has actually taken place. This information should already be in the roster for the room, but since the same presence message updates the roster, I suspect I would have to dispatch the grant/revoke voice event in the same code that updates the roster, but before doing so … in order not to lose the old role. Still looking at this, but as always I am interested in hearing if anyone else has been down this road and found a suitable solution.
I have implemented 4 new events for Room.as … USER_KICKED, USER_BANNED, REVOKED_VOICE, and GRANTED_VOICE. I probably could have implemented them without modifying the core XIFF code, but it would have been more work. Given the number of other changes I have already had to make to the core XIFF code, I figured I might as well make this a part of the core implementation rather than a bolt on specific to my application. Still testing, but it appears to work fine so far. If anyone is interested, let me know.