Ah, so it is supposed to work like that :)
It didn't quite work, here's the code:
* **transmitter.sendUserListRequest(peer, invitationID);*
/*
* TODO: Wait until all of the activities in the queue (which
arrived
* during the invitation) are processed and notify the host only
after
* that.
*/
sessionManager.sessionStarting(sarosSession);
sarosSession.start();
sessionManager.sessionStarted(sarosSession);
sessionManager.preIncomingInvitationCompleted(monitor);
*sarosSession.userInvitationCompleted(sarosSession.getLocalUser());*
As far as I understand, sendUserRequest() isn't blocking, so the invitation
may be set to
completed before the userList sent from the host is handled.
I guess if the TODO were done, your suggestion would work.
2012/9/7 Stefan Rossbach <srossb...@arcor.de>
> boolean de.fu_berlin.inf.dpp.User.isInvitationComplete (
> )
> *Returns:* false if the invitation is currently in progress, true if
> the invitation process is complete
>
> Maybe you should try this method. Should work (I think at least, I am not
> sure).
>
> Am 07.09.2012 13:09, schrieb Arsenij Solovjev:
>
> Dear Sarosians,
>
> First, let me introduce myself (I think I haven't yet). My name is
> Arsenij, im a Masters Student at FU Berlin, and currently am working on
> Saros
> within the Softwaretechnik Projekt 2012.
>
> We are working on the bugfix for
> http://sourceforge.net/tracker/?func=detail&group_id=167540&atid=843359&aid=3514675
> .
> The faulty behaviour is that Saros doesn't discriminate whether a userList
> is receives is part of the invitation process, or happens
> some time later in the session. In the first case Saros should not display
> a balloon notification that a buddy has joined the session,
> and in the second one it should
>
> We've come to the point where we have several options how to solve the
> problem, and we'd like your help on how to proceed:
>
> 1. Hack
>
> See if sarosSession.getProjects().size==0. This an indication for the
> peer to know whether the project negotiation is over.
> If the project negotiation is not yet over, then it is assumed the
> userList received is the first one and notifications for new buddies
> found can be neglected
>
> 2. Provide a flag for initial userList
>
> Provide userList stanzas with an additional flag, which says whether this
> userList is the first userList sent to the peer.
> This way the peer knows that all buddies it sees as new buddies have
> already been in the session before him, and notifications for new buddies
> can be neglected.
>
> 3. Add a listener
>
> This is in essence the same fix as 1: Add a listener which listens for
> projectAdded(), which is called after project negotiation is done.
> When a project has been succesfuly added the listener would set a flag in
> sarosSession, which says whether the project is still in negotiation.
> Frankly, I was surprised not to find any such flag already...
>
> The possible problems with 1. and 3. would be that a buddy might join the
> session while the project negotiation is not over yet, and his
> joining would not be notified. Is this a real concern?
>
> Can anyone see further issue with solution 2.?
>
> Cheers,
> Arsenij & Patrick
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Dpp-devel mailing
> listDpp-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/dpp-devel
>
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dpp-devel mailing list
Dpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
