Bug 27107

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.