Opened 14 years ago

Closed 10 years ago

Last modified 9 years ago

#935 closed defect (obsolete)

Re-launching shared activities from the Journal does not Do The Right Thing

Reported by: bemasc Owned by: tomeu
Priority: Normal Milestone:
Component: sugar-presence-service Version: Unspecified
Severity: Major Keywords:
Cc: sascha_silbe Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

Case 1: Suppose user A starts an activity session, shares it with B, and then exits. The shared session is still running, with B (and maybe other users), although because of of bug #943, A cannot see them in the Neighborhood View. A now goes to the Journal, and re-launches the shared instance. When the activity is initialized, Sugar tries to re-set the scope to shared... but it does not connect with the existing shared session! Sugar should send the "joined" signal to indicate that it has connected to an existing shared session, but instead it sends the "shared" signal, which indicates that a new shared session is being started. As a result, the initiator is now running a distinct, new shared session.

Case 2: Suppose A starts an activity and shares it. B joins, and then leaves. A then leaves too, and the session disappears. B, looking at her Journal, sees a saved session in A's colors. If B re-launches the shared session, Sugar automatically causes it to be shared... but now it has A's colors, and so is not recognizable as the same session as before.

There is exactly one case that does work:
Case 3: A starts a shared session. B joins, then leaves, then decides to re-join again. B re-launches from the Journal, and it automatically re-connects to the existing shared session.

Change History (9)

comment:1 Changed 14 years ago by sascha_silbe

  • Cc sascha_silbe added

comment:2 Changed 14 years ago by bemasc

Oops, the description should say #934, not #943

comment:3 follow-up: Changed 13 years ago by uwog

Case 1 seems to be described wrong: "A now goes to the Journal, and re-launches the shared instance. When the activity is initialized, Sugar tries to re-set the scope to shared... but it does not connect with the existing shared session!"

From my observation, it DOES connect to the existing tube: when I broadcast a bogus packet over the tube "B" will actually see it. I agree with the observation that the wrong 'shared' signal is sent out through.

comment:4 Changed 13 years ago by uwog

I confirm case 2 and 3 too.

comment:5 in reply to: ↑ 3 Changed 13 years ago by bemasc

Replying to uwog:

From my observation, it DOES connect to the existing tube.

I concur; it does connect to the existing tube. This bug, then, is just a matter of sending the right signal.

comment:6 Changed 13 years ago by tomeu

  • Component changed from sugar to sugar-presence-service
  • Milestone changed from Unspecified by Release Team to 0.86
  • Owner changed from tomeu to morgs
  • Priority changed from Unspecified by Maintainer to Normal
  • Severity changed from Unspecified to Major

comment:7 Changed 13 years ago by tomeu

  • Owner changed from morgs to tomeu
  • Status changed from new to assigned

comment:8 Changed 10 years ago by dnarvaez

  • Resolution set to obsolete
  • Status changed from assigned to closed

comment:9 Changed 9 years ago by dnarvaez

  • Milestone 0.86 deleted

Milestone 0.86 deleted

Note: See TracTickets for help on using tickets.