Code review comment for lp:~kevin-wright-1/u1db-qt/synchronizer-merged-with-trunk-8-aug

> Assuming too much about what the app developer wants, the endless
> possible types of errors that might be encountered (e.g. faulty app
> logic, user input variations, API problems), or who their audience is,
> along rigid lines (and then use that logic for designing the API), may
> be asking for trouble. What one developer to the next might want (or
> need) could be different enough that "signal syncFailed" isn't enough.
> This is why I suggested having a much more flexible and less
> discriminating approach of making the data vailable using QVarientMap,
> with meta data included so u1db dev and app dev can use the information
> in ways they choose, for the ultimate benefit of the end user.
>
> The existing approach is indeed immature in that respect, but the
> suggestion of using a model (QVarientMap) moves beyond current
> limitations and is flexible enough for a broad set of use cases, some of
> which we cannot anticipate on our own, but without creating huge overhead.
>
> It is intended to provide a rich mechanism for developers to create
> robust applications for users that do more than simply give feedback
> that only says "fail". Additionally it can hopefully provide useful
> information for u1db-qt devs as well (who also might happen to build
> apps with the plugin...including examples).

syncFailed was an example only. And I stress free-form strings are not a basis for proper error handling API.

At this point I'd prefer to only use simple qDebug() calls and leave proper error API for a separate task. I created bugs for this: bug 1210448 and bug 1210450.