#25 Let user select the "active" client

open
nobody
SIPE Core (15)
5
2010-02-15
2010-02-15
No

@pier11: I think you have the best overview if this feature is possible at all. Feel free to close it if this is not possible.

It is not clear how OCS handles 2 or more Sipe (maybe also other) active clients for the same account:

- which client receives IM invites?
- which client receives Chat invites?
- if the calendar state cycles (i.e. those 5 minute checks) in the client are not synchronized, does one client override the calendar state change of the others?

At least in my "real life" observation the behaviour is random at best. The only thing that is really "fixed" is that if you start an IM/Chat from one client then it stays on that client.

It would be nice if the user could tell OCS what *HE* considers to be the *active* client. I see several possibilities:

a) automatic: last logged in client is the active one
b) automatic: where the user is typing (in any window or only Sipe IM/char?) is the active one
c) manual: Sipe menu "Set as active client"

F.ex. sametime plugin at least used a)

Discussion

  • pier eleven

    pier eleven - 2010-02-15

    With regard to Calendar.
    If our client knows about Calendar (read in communicates with Exchange), then it (in 5-min loop) will send updates (if exist) to CALENDAR STATE only to the server. Obviously, if it doesn't have calendar data, it won't.

    Our aggregated state is calculated on the server based of all state entries: Calendar, User, Machine (idle/not), Phone... Then we display the aggregated state in the statusbox in UI. So our status is the same for all our clients, whether they are "Calendar-enabled" or not. (If several our clients publish such an info - that's fine too as long as the source of calendar data is the same, so publications will be the same.)

     
  • Stefan Becker

    Stefan Becker - 2010-02-15

    So if I understand this correctly: Sipe clients auto-answer invites, so it depends which reply arrives at the OCS first. Correct?

    Is it possible to detect for a Sipe client that another client is active (and more importantly goes offline!) and change the behaviour accordingly?

     
  • pier eleven

    pier eleven - 2010-02-15

    By auto-answer I meant to accept Incoming INVITE. Not to actually send any automatic text human readable.

    roaming-self subscription should have information on all active user's endpoints. So analyzing it would give information whether we in single or multiple-point-of-presence mode.

     
  • Stefan Becker

    Stefan Becker - 2010-02-15

    Does roaming-self get updated (i.e. an on-line client receives an update) when
    - a new client goes on-line?
    - a client goes off-line, either by itself (user quits) or server disconnect?

     
  • pier eleven

    pier eleven - 2010-02-15

    I think yes. We are subscribed to it. And OCS is more than happy to send us any updates caused by other points of presence.
    Anyway official client understands if it's in single mode or not.

     
  • Stefan Becker

    Stefan Becker - 2010-02-15

    First attempt at a state machine:

    A: client auto-answers to any INVITE it receives (default state after connect)
    B: client does not answer to INVITE it receives (*)

    in state A:
    - client receives roaming-self indicating that a new client has gone on-line -> go to state B
    in state B:
    - client receives roaming-self indicating that a client has gone off-line -> go to state A (**)
    - user selects "set as active" menu -> update OCS (***) -> go to state A

    (*) possible alternative: delays auto-answer for 10 seconds (like MS client), if "active" client has already answered before that, our INVITE answer should be rejected by OCS. Correct?
    (**) if there are still 2 or more clients active at this point, who gets to be the active one? Should we wait for a random amount of time (up to 10 seconds?) and then do (***)?
    (***) how would that be done?

    As long as there is only one active client, it would stay in state A, i.e. it would behave like the current implementation.

     
  • Stefan Becker

    Stefan Becker - 2010-02-15

    Two additions:

    (*) if our delayed response to INVITE does get accepted then it means the "active" client is no longer "active" -> go to state A

    in state B: if the user initiates a new IM/Chat, i.e. our client sends out an INVITE -> go to state A

    I think (***) is the key to all of this. When we go from B to A we always should do (***) so that other clients know about our state change.

     
  • pier eleven

    pier eleven - 2010-02-15

    There is no such a notion as an active client. We shall behave the way OC does to be able to work with it in parallel.

    In OC world ALL clients present user with so called "toast" - a small pop-up window above the icon area in lower right corner of windows desktop for 10 sec. (In a multi scenario). This toast present user with the first message and gives him option to click to start an IM dialog window. If no action is taken by user, it'll disappear after 10 sec. (So IM dialog won't be opened for this client. And it will not answer incoming INVITE - which was forked to each point of presence, or will more likely send CANCEL)

    If on some of devises user click on the toast, it will lead to IM dialog open and to accept of incoming INVITE.
    So user himself defines which device to use to answer the incoming IM (for ex. Communicator Mobile on PDA or on the Laptop) And it doesn't matter which device has been logged first.

     
  • Stefan Becker

    Stefan Becker - 2010-02-16

    I understand that this is the behaviour of the M$ clients.

    But why ask the user if we can automatically determine the correct action? Why do we need to interrupt the user while he is typing, e.g. in Pidgin, with a stupid question, instead of opening the IM/chat automatically in this, the obviously active client?

    Anyway it will be easy to configure this with an additional preference option "Multiple Client Behaviour" - "Smart"/"Ask user"/"Auto answer".

     
  • Stefan Becker

    Stefan Becker - 2010-12-12

    Information copied from duplicate #3135016:

    The scenario:
    - User is using two computers
    - User is logged in on them (using either Office Communicator R2 or Pidgin-SIPE)
    - Another user IMs it

    Correct use:
    If the user is using only Office Communicator, a popup will show on both clients. Use is able to accept the message on one. Further messages are delivered on the client with the open window. Is the user closes the window, the next message will again trigger a popup.

    Pidgin-SIPE:
    If the use is connected to Office Communicator and Pidgin-SIPE, the last will always accept the IM. User will never see the IM on communicator.

    My response:
    I'm not sure if this can be implemented at all. It would depend on
    libpurple offering an API to present such a request to the user.

     
  • Stefan Becker

    Stefan Becker - 2011-06-03

    I've pushed some experimental code for this. I haven't implemented the toast, so IMs in MPOP situations will now be 10 seconds delayed before the chat window opens.

    This definitely needs refinement.

     
  • Ricardo Duarte

    Ricardo Duarte - 2011-06-12

    Hi,
    You patch works great when the multiple clients are OCS, but it does not work when the multiple clients are web (I tried with Exchange OWA only).
    Pidgin will accept all the messages before giving a chance for the web interface user to answer.

     
  • Ricardo Duarte

    Ricardo Duarte - 2011-06-12

    Just some follow up:
    - If I start the web client and after that I start Pidgin, it will work as it should. Pidgin waits 10 seconds.
    - If I start the web client before starting Pidgin, the last will accept messages immediately. It seems like it only checks for MPOP when it starts.
    Regards.

     
  • Ricardo Duarte

    Ricardo Duarte - 2011-06-12

    Sorry, write it wrongly.

    - If I start the web client *after* starting Pidgin, the last will accept
    messages immediately. It seems like it only checks for MPOP when it starts.

    Some scenarios and results:

    login web -> login pidgin = pidgin takes 10 seconds before accepting the message (ok)
    login pidgin -> login web = pidgin accepts messages immediately (nok)
    login web -> login pidgin -> relogin web = pidgin accepts messages immediately (nok)
    login pidgin -> login web -> relogin pidgin = pidgin takes 10 seconds before accepting the message (ok)

     
  • Stefan Becker

    Stefan Becker - 2011-06-12

    Please check the Pidgin debug log for the time stamp when you go active with the Web client. If you don't see a roaming_self update, then pidgin-sipe can't know that you are online with another client. I didn't test the Web client when I tested the code, but all other clients logon/logoff caused a self_roaming update with an updated device list.

    (it could of course be that the Web client is that mysterious 1 active client I have seen in my logs, that's why the code substracts 1 from the devices count...)

    You'll have to provide the Pidgin debug logs from your test scenario, otherwise this is just poking in the dark.

     
  • Stefan Becker

    Stefan Becker - 2011-06-13

    Dooooh, you were right. Mystery solved: when I wrote the original code I was online with Exchange OWA 2010 which is of course an OC client. That explains the additional device instance in roaming self.

    Please try again with git commit 4fcce77.

     
  • Ricardo Duarte

    Ricardo Duarte - 2011-06-19

    Still does not work.
    If I login to web after login with Pidign, Pidgin will catch all messages immediately.
    I can see the popup on web showing up/blink for less than 1 second.

     
  • Stefan Becker

    Stefan Becker - 2011-06-19

    Did you check the pidgin debug log if it shows "multiple clients detected" after you login to the web interface. In my test it worked in any order I tried.

     

Log in to post a comment.