[Bug 27274] Make the telepathy logger extensions library public

[bugzilla-daemon at freedesktop.org]

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





--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-03-24 12:58:47 PST ---
(In reply to comment #1)
> It should include a TpProxy subclass: TplLogger.

Yes, it should. It's more or less OK for local extensions to paste
functionality onto (every) TpProxy, but libraries shouldn't do that.

Also, this would allow adding a TP_ERRORS mapping, which can't be done directly
on TpProxy (an artificial restriction I put in to stop people causing
collisions by defining two mappings for the same set of D-Bus errors).

How stable is the D-Bus API, compared with the real library? If it's not
terrifyingly unstable, then it should just be part of the real library, in the
same way that TpChannelDispatchOperation is part of telepathy-glib.

A final advantage of adding a TpProxy subclass is that you can put in the
correct logic and documentation for when it should get invalidated (e.g.
Channel.Closed has this effect), and whether it needs to be addressed by unique
name (stateful API) or not. From context, I suspect that the logger is
stateless and never invalidated, like TpConnectionManager, though?

Finally: is this actually as useful as you think? Does the library not already
have GAsyncResult-based wrappers for all the D-Bus methods?


--- Comment #4 from Travis Reitter <travis.reitter at collabora.co.uk>  2010-03-24 14:33:17 PST ---
(In reply to comment #3)
> (In reply to comment #1)
> > It should include a TpProxy subclass: TplLogger.
> 
> Yes, it should. It's more or less OK for local extensions to paste
> functionality onto (every) TpProxy, but libraries shouldn't do that.

> A final advantage of adding a TpProxy subclass is that you can put in the
> correct logic and documentation for when it should get invalidated (e.g.
> Channel.Closed has this effect), and whether it needs to be addressed by unique
> name (stateful API) or not. From context, I suspect that the logger is
> stateless and never invalidated, like TpConnectionManager, though?

The API is stateless.

> Finally: is this actually as useful as you think? Does the library not already
> have GAsyncResult-based wrappers for all the D-Bus methods?

Yes, these wrappers exist and they work reasonably well (I'm using them in
another project).


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