[Telepathy] Our error reporting sucks

[Olivier Crête]

First, thank you for answering, although with a 3 months delay!

On Wed, 2008-12-03 at 17:33 +0000, Dafydd Harries wrote:
> Ar 28/08/2008 am 16:45, ysgrifennodd Olivier Cr??te:
> > Hello,
> > 
> > After spending too much time already trying to debug errors coming out
> > of a connection manager, I've come to a simple conclusion: Telepathy
> > error reporting SUCKS! 
> > 
> > As a first step, I propose adding translated error strings to the dbus
> > errors.. So that instead of getting only "NetworkError", we'd also get a
> > strings that says "Could not resolve a.b.c". Obviously, the UIs could
> > ignore the string and the CMs don't have to emit a message with every
> > error.
> 
> How exactly do you propose we add an extra string? In the case of D-Bus method
> return errors, there isn't a place for us to put extra structured data. In the
> case of asynchronous errors, I don't see how to do without breaking API in a
> pretty nasty way.

Well, for dbus error, there is already a string parameter, isn't there ?
And this isn't structured data, its a string...

Async errors have been done wrong, accept it, break the API/ABI and fix
it. Or for every case add a new signal "SignalNameWithUsableError" and
then new clients can use these and old ones use the old one (that can
all be abstracted by tp-glib).

> I don't really like the idea of adding translations to connection managers.
> Either error conditions are common, in which case we should standardise them,
> or they're uncommon, in which case they should stay in the form of debug
> information. The problem is that we've been using integer enumerations of
> error conditions, which are difficult to extend in ABI-preserving ways.


If we want to avoid translated strings in the CM (I don't really see
why, they run in the same desktop session as the rest of the crap). We
can add LOTS more stuff to the error enum. But to make it useful, we
still need a string with extra information (like if we had an error
"can't resolve", then we'd also add a string with the hostname).
Anyways, the current API is broken and needs fixing



> > Also replace the org.freedesktop.Telepathy.Connection.StatusChanged
> > signal with StatusChangedMessage(uus) where the string is the reason for
> > the status change (I'm especially thinking of the NetworkError reason
> > here). 
> > 
> > Also, I propose adding new log retrieval interface and make it mandatory
> > on the ConnectionManager object and optional on the sub-objects (the
> > Connection and Channels).
> > 
> > Something like org.fd.tp.LogRetrieval with this method:
> > GetLog(u: Number of Lines to return u: Min log level) -> a(us)
> > Where u would be the log level for that line (and s the string)
> > so the UI can display/colorise it properly.
> 
> This is a good idea, but I think probably a per-service debug object is easier
> to interface with. I think it should probably be something like:
> 
>   EnableDebugging() -> a(us)
> 
> I'm not sure the minumum log level parameter is very useful: you can filter
> that out on the client side. Also, calling this function would make a D-Bus
> signal be emitted for each debug message. This means that a debugger can watch
> a session without having to poll for logs. It might even be possible for
> dying services to send assertion failure messages over the bus.
> 
> I think each service should probably have a global debug object. 

That means its hard to filter errors per telepathy "connection" .. so
they may get mixed up pretty hard if you have multiple accounts...

The minimum level is because stuff like GST can produce immense amounts
of output at the highest log levels..

-- 
Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20081203/5c142502/attachment.pgp