[Bug 29614] Allow a user-specified TpAccountManager on TpBaseClient

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-23 09:44:25 PDT ---
(In reply to comment #2)
> You probably want to check that the bus is the one the AccountManager object
> given to TpBaseClient is on if both are specified.

I thought about that, but I couldn't see why it strictly *needed* to be
forbidden... better to forbid suspicious things now and relax our checks later,
though, so I'll do that.

> Also, in likely-account: in which cases exactly can the account not be the
> likely account? (The filter is empty, so MC shouldn't dispatch anything to us
> apart from our request which will indeed have the same account). Somebody
> guessing our service name and setting it as a preferred handler?

Yes, or even someone who isn't MC calling our HandleChannels function directly.
We should try to behave correctly in either case. I can see that having
HandleChannels fail might be considered more correct here than trying to cope,
though, so I'll change the semantics from "likely account" to "only this
account" and make HandleChannels raise InvalidArgument for other accounts.

> IF there are valid corner-cases, in which this can happen, then shouldn't we
> actually pass the account's AccountManager, if any, to the TpBaseClient rather
> than just the bus, to get correctly shared accounts outside the singleton AM
> instance even if it's not the likely account?

The account needn't have an AccountManager at all, in an asymmetric Handler
that never actually needs to list accounts because it never initiates channels
(a file transfer receiver, or a VNC client accepting a stream tube).

(In reply to comment #3)
> Could you elaborate a bit more in TpBaseClient:account-manager: why/when a user
> would want (or not) to pass a specific AM. I know why but I think that would be
> less clear for people not familar with TP as that's pretty subtil.

Yes, I should do that.

> Do we really need new_with_am variants for TpSimple objects? We could claim
> that if you don't want to use the "default" AM you are not that simple any more
> and so should use TpBaseClient directly.

The simple handler is simple along a different axis :-) It's a way to handle
channels without paying the boilerplate cost for a subclass.

If we'd thought of this stuff up-front, I'd have made _new() take an AM and not
had a TpDBusDaemon version at all, but we're stuck with the _new() versions
now. It might even be worth deprecating them.

> I'd add a small comment explaining why/when 
> _tp_base_client_set_likely_account() could be used.

It's basically just for TpAccountChannelRequest; I'll say so.

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