#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
comment:3 follow-up: ↓ 5 Changed 14 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 14 years ago by uwog
I confirm case 2 and 3 too.
comment:5 in reply to: ↑ 3 Changed 14 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 14 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 14 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
Oops, the description should say #934, not #943