> On Fri, 2009-11-13 at 10:13 -0500, Robert Joly wrote: > > Hi, > > When I started implementing the SIP State<->XMPP Presence > integration > > feature I was debating in my mind how exactly that feature would be > > presented to the user. In the end, I decided that the SIP State > > information would only affect the XMPP status message by > pre-pending > > 'on the phone' to it but that the XMPP presence state would remain > > unaffected. So, for example, if idle user XYZ has an XMPP status > > message of 'in the lab' and an XMPP presence state of > 'Available' then > > when he becomes on the phone, his XMPP status message will get > > automatically changed by the feature to 'on the phone - in the lab' > > but his XMPP presence state will remain as 'available'. > The reasoning > > behind the choice of not changing the XMPP presence state > comes from > > my own IM habits. > > It happens very frequently that I have one or more IM conversations > > while I am on the phone with someone else. So, for me, > being on the > > phone does not imply that I'm not available for IMs and > that is why I > > chose not the automatically make XMPP users appear as busy > when on the > > phone. Having said that, if I'm in a very important phone call, I > > will sometime change my XMPP status to DND to reflect that. > > > > I do realize that all this is very centered around my personal > > preferences, that is why I will bringing up this topic on > the dev list. > > Perhaps it would make sense to expose another user-level XMPP > > preference setting (would be the 4th) that determines > whether or not a > > given user wants his XMPP presence state to be > automatically changed > > while he is on phone. > > > > What do you think? > > Initially (before I had used it much), I thought that the > base status should change in addition to adding the text. > Now that I've been using it for a few weeks, I decided that I > like the way it is. > > The option you suggest would be ok, but there are two > problems with it: > first - all options are evil and if we don't really have to > do it now then I think it's best not to.
I'm not crazy about having the option either. > More importantly, > it creates two > overlapping points of control. How would manual changes made through > my client interact with this? > > Suppose I've set the option to switch me to DND when on the > phone. What should be my status be after this sequence: > > 1. I manually set my status to Away > 2. I begin a phone conversation (status changes to DND?) > 3. I manually set my status to Available > 4. I end my phone call The real challenge in arbitrating these interactions is not the coding part itself - this part is simple and I have a 'PresenceUnifier' object that receives all the necessary inputs to implement pretty much anything we want. The challenge is in defining the heuristic that will lead to the results a user would expect. I didn't spend much time on that part just yet but I was thinking to keep this really simple and go to DND whenever the user goes on a call and then return to the last user-supplied state when the phone call ends. Keeping with this, here is the presence state that I propose would be advertized for each one of the steps of the sequence you defined above: 1- Away 2- DND 3- DND 4- Available _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
