[Bug 28866] Allow channel requesters to associate metadata with requests for the benefit of other clients

[bugzilla-daemon at freedesktop.org]

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

--- Comment #15 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-09-06 01:30:04 PDT ---
(In reply to comment #14)
> I've stolen this branch:
> 
> http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/request-channel-25018
> http://people.freedesktop.org/~smcv/telepathy-spec-request_channel_25018/spec/
> 
> The *implementation* of this branch turns out to be quite a can of worms (not
> Guillaume's fault, it touches MC code that contains lurking horrors) so I think
> we need to get it merged relatively soon (before the spec is undrafted) and
> refactor until it actually makes sense.

++ for merging earlier as a DRAFT/FUTURE.

> Accordingly, I've moved the new API to .FUTURE pseudo-interfaces, so we can do
> the refactoring without needing to compile MC against a patched telepathy-glib.
> I opened Bug #30000 (eek, 30k Freedesktop bugs) for the MC implementation.
> 
> I've also made some other misc changes, for which see my git repository.

Your patches look good to me.

> To-do list
> ==========
> 
> Should SucceededWithChannel have the immutable properties of the channel? I
> think it probably should, but I haven't added this yet.

I think so, we should encourage clients to always use
tp_channel_new_from_properties()

> Should SucceededWithChannel be plural? In principle, a ChannelRequest could
> operate on a hypothetical plural request, and return many channels... although
> plural requests are a tower of cans, each containing worms.

Right, we're not going to solve the plural request problem now but making it
plural would ensure that this new API is future ready.

> Should SucceededWithChannel give you properties of the Connection? Probably
> not, IMO: connections don't have many (useful) properties that are actually
> immutable!

I agree that's not really useful atm but, oth, the "path + immutable
properties" pattern is an useful one so it would probably be good to generalise
it. Maybe that could actually be a Telepathy 1.0 goal?

I wouldn't be surprised that at some point Connection objects gain immutable
properties  at some point.

> Should we explicitly say that the CD will never interpret Hints? I think we
> should, and I've added a commit that says so.
> 
> While we're adding new ways to request channels, should we add an a{sv}
> placeholder for extra arguments that the channel dispatcher *does* interpret?
> (Obviously, this is unnecessary if you convince me that my previous assertion
> was wrong.)

I don't have a strong opinion on this.

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