Hello Patrick, On Oct 25, 2011, at 10:46 , Patrick Ohly wrote:
>> 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. Ok, that is a bit of context needed to understand the initial statement :-) But if the superdatastore was changed from probing with ReadItem to directly probing/deleting with DeleteItem, the error reporting would look similar, as it would show failed deletes for those subdatastores not containing the object in question. I mean, for deleting a todo from the calendar superdatastore item you'd see something like "calendar: failed deleting item xy" and "todo: deleted item xy ok" (don't know if success is shown as well). Would this be any better / more understandable? Best Regards, Lukas Zeller, plan44.ch l...@plan44.ch - www.plan44.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
