[Etoys-notify] [JIRA] Updated: (SQ-197) Work around presence bugs

jira at immuexa.com jira at immuexa.com
Wed Apr 29 17:58:04 EDT 2009


     [ http://tracker.immuexa.com/browse/SQ-197?page=all ]

Scott Wallace updated SQ-197:
-----------------------------

    Fix Version: M5: olpc nice-to-haves (sep)
                     (was: triage)

> Work around presence bugs
> -------------------------
>
>          Key: SQ-197
>          URL: http://tracker.immuexa.com/browse/SQ-197
>      Project: squeakland
>         Type: Bug
>   Components: etoys-plugin
>     Reporter: team
>     Priority: Eventual
>      Fix For: M5: olpc nice-to-haves (sep)

>
>
> From TRAC Ticket #8699 (bert, sept 2008)
> Sometimes the presence service delivers malformed data, which makes Etoys show an unpleasant error dialog.
> The scenario goes like this: two XOs connected to same access point, but in the neighborhood view only one can see the other. Trying to share anyway makes the shared activity appear in only one XO's neighborhood. Joining it works fine, also the Joined() signal for the remote buddy is delivered, but accessing the joined buddy's properties gets all blank strings, in particular no key. But shortly after that we receive a tube which does have a valid buddy key (Etoys is fortunately putting it into the tube properties). From that info we could construct a dummy buddy because the key and tube address is really all we need to communicate back.
> Last seen in joyride-2489.
> (bert) Actually, we could always wait for the tube signal and only then create the buddy badge, it's useless before we get a tube to communicate with that buddy anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://tracker.immuexa.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira



More information about the Etoys-notify mailing list