Re: [SyncEvolution] [os-libsynthesis] super data store: trying to read to check for existance
On Tue, 2011-10-25 at 10:16 +0200, Lukas Zeller wrote:
> That sounds like the right compromise. I'm much more
comfortable
> returning 404 in a delete and not reporting that to the user as an
> error, compared to not reporting a 404 in a ReadItem call (as I have to
> do now).
Now I don't understand. Why do you have to *not* report a 404 in
ReadItem now??
Reporting to the engine is fine, reporting to the user is the
problematic part. Let me explain.
The SyncEvolution output, the one that is visible to end-users, contains
INFO and ERROR messages about operations happening in the backend. Each
attempt by the Synthesis engine to read a non-existent item results in a
user-visible error. Or rather, two of them in the case of a super data
store combining "calendar" and "todo":
[ERROR] error code from SyncEvolution fatal error (local, status 10500): calendar:
retrieving item: 20111023T082825Z-2322-1001-1969-0@lulu-rid: Objektpfad des Kalenders kann
nicht abgerufen werden: Objekt nicht gefunden
[ERROR] error code from SyncEvolution fatal error (local, status 10500): todo: retrieving
item: 20111023T082825Z-2322-1001-1969-0@lulu-rid: Objektpfad des Kalenders kann nicht
abgerufen werden: Objekt nicht gefunden
At the point where that logging happens it is unknown whether the error
is really a problem or can be ignored. Only the Synthesis engine itself
knows. When I started to use the Synthesis engine, I tried to make the
logging happening inside the engine visible to users, but it simply
wasn't meant to be used for that and so I gave up on that approach.
Admittedly the ERROR message above is not very informative either.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.