[Bug 24661] Define per-connection "sidecar" objects

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Oct 22 20:45:00 CEST 2009


http://bugs.freedesktop.org/show_bug.cgi?id=24661


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://git.collabora.co.uk/?|
                   |p=user/wjt/telepathy-spec-  |
                   |wjt.git;a=shortlog;h=refs/he|
                   |ads/sidecars                |




--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-10-22 11:44:58 PST ---
(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.


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


More information about the telepathy-bugs mailing list