(In reply to comment #0)
> I wonder whether, instead of a map from full path to immutable properties, it
> might be better to have a map from string to immutable properties, where the
> string is an extra component to stick at the end of the connection's path. That
> would allow clients to look up (eg) the "OLPC" sidecar, rather than looking
> through the hash table for a sidecar that implements the org.laptop.Misc
> interface.

That does sound like a win, but it would mean the keys were strings rather than entire object paths (which is in practice a source of confusion within Mission Control - about half the variables are just the unique tail of the object path or bus name, and the other half are the whole thing - which I'm trying to eliminate by normalizing to the whole thing).

Other possibilities include:

* that, but namespaced: org/laptop/Misc (leading to the object /o/f/T/C/gabble/jabber/foobar/org/laptop/Misc)
* have the entire object path as the key, but have the client compute the object path by appending the tail it wants to the connection's object path, then look that up
* declare that sidecars (may? must) have a Type like channels do, which makes it a little easier for clients to scan through the hash table (one hash lookup per sidecar, rather than one hash lookup plus one linear search of a GStrv or equivalent)

> (Suggestions for a better name than “sidecar” welcome.)

I think the namespace should probably mention Connection somewhere (o.f.T.Connection.Sidecar? o.f.T.ConnectionSidecar?), although I could be persuaded otherwise.

Appendage? Appendix?

I'd say extension, but conventional telepathy-glib usage already assigns a meaning to that.

quick note from spec cabal: a{s: main interface => (oa{sv}): details}

Untagging, needs more work. Assigning to Will for the more work.

Working on updated spec.

Updated:

• The Sidecar interface is gone;
• The Sidecars property is an a{s(oa{sv})} as above.

See <http://people.freedesktop.org/~wjt/telepathy-spec-sidecars/spec/org.freedesktop.Telepathy.Connection.html#org.freedesktop.Telepathy.Connection.Sidecars> for the property's documentation; my 'sidecars' git branch is at <http://git.collabora.co.uk/?p=user/wjt/telepathy-spec-wjt.git;a=shortlog;h=refs/heads/sidecars>.

That looks good to me, but I'd prefer it diverted off into Connection.FUTURE for the initial release in the spec and implementation in Gabble.

So I've been agonizing about this some more. Having the only change notification for Sidecars being the connection moving to Connected seems like a great idea, but in fact may not be. On XMPP, we could imagine sidecars being dependent on server components returned in the disco#items query to the server, so you have to disco a whole bunch of jids — which might be on different machines to your server, and may have fallen down a well so you need to wait for them to time out — before you move to Connected. (Gabble currently moves to Connected before doing any of this, presumably for this reason.)

So, I thought to myself, we need a SidecarAdded signal. But actually that's not good enough: clients need to be able to know whether a sidecar will ever show up, or if they're going to be sitting around waiting for SidecarAdded forever.

Let's add a method:

  RequestSidecar ( s:     Interface)
               → ( o:     Sidecar_Path
                 , a{sv}: Properties
                 )

Then a client which wants a particular sidecar can just call that method, and when it returns deal with the error or use the sidecar. Given this, there's relatively little need for the Sidecars property at all: if you want one, ask for it.

Explicitly requesting sidecars also means that if a sidecar is expensive in terms of network traffic, it doesn't have to be initialized unless someone actually wants it.

Thoughts?

Pushed the latest version of this, and uploaded the documentation at <http://people.freedesktop.org/~wjt/telepathy-spec-sidecars/spec/org.freedesktop.Telepathy.Connection.FUTURE.html>.

There's now one method:

  EnsureSidecar ( s:     interface )
              → ( o:     sidecar_path
                , a{sv}: immutable_properties
                )

which you can call whenever you like, and get a sidecar back for that interface. It assumes that there's only going to be one sidecar per (connection, interface), with the rationale that if you want to expose more than one object with a given interface, you can either make them children of your sidecar or make them channels.

I think this is ready for spec cabal bikeshedding, particularly given that I've implemented it in Gabble and it seems to work. :-)

review+ from me as a draft. On the 0.19.0 wishlist.

Draft exists in 0.19.0; repurposing this bug for a final version in future.

I played a bit with sidecars recently and would like to discuss some points regarding them.

- Currently once loaded side cars object stay alive during all the lifetime of the connection right? Maybe we could do the same kind of magic than in the client interest branch and destroy it once all the clients than ensured it are gone?
This could be useful for example, if sidecars subscribes to some PEP ou pubsub nodes to reduce XMPP traffic.

- Speaking of client interests. As I pointed on bug #27948, clients can't use this API as sidecars's interface are not on the connection object; that could be annoying. Note that if we destroy sidecars as I suggested above that could be less of an issue.

- Same question regarding the Contacts interface. Could we imagine adding attributes which are not interfaces on the Connection object? The spec doesn't seem to say we can't and that should be easy to implement as the sidecar has access to the connection object (it just have to call tp_contacts_mixin_add_contact_attributes_iface on it).

- Assuming sidecars would be able to use the Contacts interface, it could be handy for clients to be able to define their own contact features and hook it to TpContact. So they'd just have to pass an extra feature to tp_connection_get_contacts_by_handle() to magically get the extra data. That's more a tp-glib issue than a spec one but I'm wondering how crack this idea is.

(In reply to comment #11)
> - Speaking of client interests. As I pointed on bug #27948, clients can't use
> this API as sidecars's interface are not on the connection object; that could
> be annoying. Note that if we destroy sidecars as I suggested above that could
> be less of an issue.

I changed the wording to be vague enough, and the API to be flexible enough, that I think sidecars can use client interests fine.

> - Same question regarding the Contacts interface. Could we imagine adding
> attributes which are not interfaces on the Connection object? The spec doesn't
> seem to say we can't and that should be easy to implement as the sidecar has
> access to the connection object (it just have to call
> tp_contacts_mixin_add_contact_attributes_iface on it).

I'd be happy to adjust the spec wording so it specifically allows this.

> - Assuming sidecars would be able to use the Contacts interface, it could be
> handy for clients to be able to define their own contact features and hook it
> to TpContact. So they'd just have to pass an extra feature to
> tp_connection_get_contacts_by_handle() to magically get the extra data. That's
> more a tp-glib issue than a spec one but I'm wondering how crack this idea is.

This is rather problematic in telepathy-glib, because TpContactFeature is an enum rather than a (quark isomorphic to a) string, so there's no namespacing. We could add an orthogonal TpContactExtendedFeature mechanism or something but that's a bit full of bees.

When we break telepathy-glib ABI for spec 1.0 and/or GDBus, we should either change TpContactFeature into a quark, or change both TpProxy and TpContact features into an opaque pointer of some sort.

Created attachment 56330 [details] [review]
Protocol: add Sidecars interface

This was gathering dust in my git repository. Maybe it'd be useful if this is ever undrafted?

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