[Bug 29735] New: Roster API semantics are error / race condition prone

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29735

           Summary: Roster API semantics are error / race condition prone
           Product: Telepathy
           Version: git master
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: low
         Component: tp-qt4
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: ollisal at gmail.com
         QAContact: telepathy-bugs at lists.freedesktop.org


I noticed while fixing the tp-qt4 tests to not have race conditions that the
Roster manipulation API has quite error-prone semantics. For example, the
PendingOperation returned by Contact::requestPresenceSubscription finishes at
*some* point of time, which can be either before, or after, the time the
Contact actually signals subscriptionStateChanged() to Asked or Yes, and
subscriptionState() starts returning the value corresponding to the new state.
The finish point depends on the actual underlying D-Bus event ordering and
kernel scheduling decisions. Needless to say, this makes that PendingOperation
finish event completely useless - nothing can be assumed of the Contact
object's actual state at that point.

Then again, most applications probably don't need to worry about consistency
between the PendingOperation and the Contact object state, since they probably
just throw away the PendingOperation. However, if you feel that your
application is needlessly complex due to this semantics issue, please raise the
bug severity and describe your use-case so that we can design more appropriate
semantics.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.