[Bug 25236] TpHandler - a class that implements a Client.Handler

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-04-20 05:48:48 PDT ---
(In reply to comment #7)
> It doesn't (currently) make sense to be an Observer or Approver with an empty
> list of filters. It does make sense to be a Handler with an empty list of
> filters (it means you'll only handle channels for which you are the
> PreferredHandler).

Really? I did write test approvers and observers having an empty list of
filters. They were called for all channels.

> > I'm not sure CLIENT_HANDLER_BYPASSES_APPROVAL should be a flag. It's pretty
> > different from others flags as it doesn't affect the interfaces implemented.
> 
> As of spec 0.19.5 (which is newer than this sketch) we want another such flag,
> CLIENT_OBSERVER_SHOULD_RECOVER (it's in the sketch, in fact, but is commented
> out).

I'm afraid we'll end up with a lot of different not related flags when clients
will grow more feature. But yeah, implementation detail.


> > What should do function like _tp_base_client_observe_channels()? Call a virtual
> > method or... ?
> 
> I'm not sure. I think either a virtual method or a signal emission would make
> sense; see above.
> 
> (If we also want something resembling Danielle's TpHandler, we should call it
> TpSimpleHandler, make it a TpBaseClient subclass, and have it take filters and
> a callback in its constructor for C developers' convenience; similarly for
> TpSimpleObserver and potentially TpSimpleApprover.)

I think I prefer the virtual method + callback passed to constructor for Simple
versions approach.
Signals doesn't fit very well here.

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