[Bug 27107] activity/application presence

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|telepathy-bugs at lists.freede |tomeu.vizoso at collabora.co.u
                   |sktop.org                   |k

--- Comment #11 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-03 04:58:54 PDT ---
Sorry for the review delay, we have a bit of a backlog of spec design work...

> Added in ?.??.?. (as draft 1)

0.19.UNRELEASED or just UNRELEASED, please. We grep for UNRELEASED during the
release process.

I think the Application should probably be called Application_Info?

ApplicationsUpdated has the wrong D-Bus signature; merging master into this
branch would give you a better spec-processing toolchain which would have
spotted this. I assume it's meant to be ApplicationsUpdated ( u: Contact,
a(a{sv}a{sv}): Apps ).

We could do the "focused app" thing by saying that the first app in the ordered
list is the primary one. That does lead to quite a lot of bus traffic if
someone alt-tabs a lot, though...

Alternatively, let Application_Info have type (s: Opaque_ID, a{sv}: Request,
a{sv}: Hints) (with the opaque ID only guaranteed to be unique per contact),
and advertise the primary app by its opaque ID.

Or, have Application_Map: (s: Opaque_ID => (a{sv}a{sv}): Info).

I think Guillaume is right that we should have access control for this, with
the default being "the same as my presence" (which is what happens in XMPP PEP,
in practice). However, see Bug #27752 for why XMPP PEP access control is harder
than you might think.

-- 
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.