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.



_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to