[Bug 30296] Add Addressing support to Gabble

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-09-28 12:21:26 PDT ---
(In reply to comment #3)
> This is going to be a pretty immense comment. :) First up, general comments on
> the design and your points above:
> 
> I agree that most of this should live in telepathy-glib, as you say. I like the
> design here a lot: it makes me happy that the changes to channel (manager)
> implementations were pretty small.
> 

They would be even smaller in the future if more channels derived from
TpBaseChannel.

> For channel requests: one other tactic we could use would be to make
> telepathy-glib's Requests infrastructure transform target addresses/URIs to
> TargetHandle internally, just like it already transforms TargetID to
> TargetHandle internally. This would do the job for Gabble at least;]
> 

Yup, that is where it belongs...
Also, TpDynamicHandleRepo should probably be extended to handle addressing, and
TpHandleRepoIface should have addressing virtual methods. Brothers and sisters
to tp_handle_(lookup/ensure) and tp_handle_inspect.

> Regarding static arrays of interfaces: one possible other way to deal with this
> I noticed in telepathy-ring is to have #defines that expand to a bunch of
> standard allowed properties/interfaces. Then we could easily define three
> different arrays of properties rather than having to do these error-prone
> offset tricks.

I have noticed that you really enjoy preprocessor Jedi mind tricks :)
I'll try to think up a macro, but feel free to come up with something. It's not
my strong card.

> 
> The RCC explosion is a bit surprising, but I don't think it's actively bad. The
> test situation is a pain, though. I saw you changed some assertLength(1, ...)s
> to assertLength(4, ..)... I'm not sure how best we should deal with this.
> 
> ‘...using the addressing bits for
> requests requires handle type to be omitted.’: i think that's fine. you might
> not know up-front what handle type the URI corresponds to. You could have an
> XMPP URI for a MUC. (I don't know if such a beast exists, the internet
> connection here isn't working.)

This is the opposite of what Simon suggests. I kind of like the idea of just
requesting a channel with a URI without any predetermined conception of it
being a user or a group. And then getting the channel and inspecting it's
props. That might not work well with current UIs, and that is probably Simon's
beef.

> 
> ===
> 
> Here are some nitpicks on the implementation itself:

To follow..

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