Because Telepathy isn't only for text, audio or video chat but also allows to use programs together with other people across the network, we want to provide ways for users to discover what others are doing and to share with others what they are doing. Telepathy already allows inviting other people to participate in our applications, but there isn't a standard way of discovering what others are doing. The old, Sugar-specific APIs in telepathy can be found here: http://people.collabora.co.uk/~cassidy/spec-olpc.html#org.laptop.Telepathy.BuddyInfo http://people.collabora.co.uk/~cassidy/spec-olpc.html#org.laptop.Telepathy.ActivityProperties === Use cases === 1. Sumana is writing an article about Telepathy for the GNOME Journal. She is using Abiword and would like for other Collabora employees to be able to read as she writes adding notes and suggestions. 2. Guillaume decides to take a rest during his work day and checks if any of his contacts is playing Sudoku on the network. === Requirements === 1. Publishing of which sharable applications a user is running. 2. Discovery of which sharable applications our contacts are running. 3. Information about the applications should include whatever info is needed to identify that application, and also to join the shared session.
Not sure, but we may have a 4th requirement: being able to know which of the shared applications the user is currently working on (main window has input focus). This may make more sense in task-based interfaces like Sugar's.
(In reply to comment #1) > Not sure, but we may have a 4th requirement: being able to know which of the > shared applications the user is currently working on (main window has input > focus). This may make more sense in task-based interfaces like Sugar's. Do you plan to continue to expose the current activity in Sugar? Is the UI actually using this information?
(In reply to comment #2) > (In reply to comment #1) > > Not sure, but we may have a 4th requirement: being able to know which of the > > shared applications the user is currently working on (main window has input > > focus). This may make more sense in task-based interfaces like Sugar's. > > Do you plan to continue to expose the current activity in Sugar? Is the UI > actually using this information? The present implementation is using the current activity to display buddies around activities in the neighborhood view. I haven't heard any alternatives to this design, so Sugar needs that info for now.
Follow some ideas about an API for these use cases: ==== Main scenario ==== When the user activates the "Share with everybody" menu item in Abiword, Abiword creates a DbusTube channel, then calls: Connection.Interface.Applications.AdvertiseApplication (o: Channel, a{sv}: Properties) → nothing The Empathy clients of each Collabora employee online in that moment will receive the signal: Connection.Interface.Applications.NewApplications (a(oa{sv}): Applications) Applications — a(oa{sv}) (Channel_Details_List) Empathy will display next to Sumana's avatar the title of the Abiword document, it may generate a notification as well. When a colleague clicks on the representation of the shared document, Empathy will call Connection.CreateChannel passing as Requested_Properties the properties from Channel_Details_List. This will ultimately cause the channel dispatcher to activate Abiword passing it the new channel. ==== Variant 1 ==== When Empathy becomes online, it will want to display the shared applications of each contact. For that, it will call the following method just after listening for the NewApplications signal: Connection.Interface.Applications.GetApplications (au: Handles) → a(oa{sv}): Applications Applications — a(oa{sv}) (Channel_Details_List)
(In reply to comment #4) > > When a colleague clicks on the representation of the shared document, Empathy > will call Connection.CreateChannel passing as ... It should be ChannelDispatcher.CreateChannel instead of Connection.CreateChannel.
(In reply to comment #4) > When the user activates the "Share with everybody" menu item in Abiword, > Abiword creates a DbusTube channel, then calls: > > Connection.Interface.Applications.AdvertiseApplication (o: Channel, a{sv}: > Properties) → nothing I'm wondering if we should represent an application as a channel or as a set of channels. For example an Abiword session could include a Text channel, a DBusTube channel and one day maybe a Call channel. So maybe that should be a(oa{sv}) instead. That would also fit better with MC which always present channels by batch if they are related. Downside is how are we supposed to join an activity then as we can't request more than one channel at the same time? Maybe it's time to introduce CreateChannels() as we already suggested when discussing multi filter transfer stuffs? On an unrelated topic, I'm wondering if we should have a dictionnary to store activity specific properties (as the OLPC activity properties). Or maybe we could use the tube channel properties dict for that?
Maybe we should also have some kind of access control on the information published as we have for Location: http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Connection.Interface.Location.html#properties
In the hope it's clearer, this is the proposed API: org.freedesktop.Telepathy.Connection.Interface.Applications Methods: AdvertiseApplication (o: Channel, a{sv}: Properties) → nothing GetApplications (au: Handles) → aa{sv}: Applications Applications — aa{sv} (String_Variant_Map[]) Signals: NewApplications (aa{sv}: Applications) Applications — aa{sv} (String_Variant_Map[])
One more idea for the signal (taken from c.i.Location): ApplicationsUpdated (u: Contact, aa{sv}: Applications) This would also take care of application removal (which the previous proposal lacked).
Have published a copy at http://people.collabora.co.uk/~tomeu/telepathy-spec-application_presence/spec
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.
(In reply to comment #11) > Sorry for the review delay, we have a bit of a backlog of spec design work... > > > Added in ?.??.?. (as draft 1) Done. > 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? Agreed. > 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 ). Yes, though I didn't got any warning, nor in make nor in make check. > 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. I like this better, will add a getter for the others' focused applications, a Changed signal and a setter for the owner's focused application. > 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. Ok, will see what I can do about it. Will be updating my branch soon.
(In reply to comment #12) > (In reply to comment #11) > > > 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. > > I like this better, will add a getter for the others' focused applications, a > Changed signal and a setter for the owner's focused application. Done, added SetCurrentApplication, GetCurrentApplications and CurrentApplicationUpdated. > > 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. > > Ok, will see what I can do about it. Will be updating my branch soon. For now I have just added ApplicationsAccessControlTypes and ApplicationsAccessControl so the local user can control who gets to see their updates.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/63.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.