On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote: > for EBook it is, all the async API there uses 'status' as an indicator > of the operation result in the async callback. I'm changing it to GError > too. I'm still on ECalBackend, but it seems some similar change will be > in ECal too, though I'm not sure yet, I'm not that far. I'll summarize > changes in the bug report when I'll be done with it, to have them > written somewhere.
If I understand all this correctly, it looks like what's being done here is allowing backends to report both an error code and a detailed error mesage to the client library, rather than having to set some generic and often less-than-helpful message from an error code alone. Looks like most of the impact in libecal and libebook is in the callback function signatures for asynchronous operations. The synchronous APIs will remain unchanged AFAICT. Chen/Milan: correct me if I'm wrong. You know, this might be a good time to starting talking again about a common base class for ECal and EBook. That would allow us to resolve some of the stupid inconsistencies between the two classes for common operations like opening, online/offline mode, ERROR REPORTING (ties into this thread), server crash detection, etc. It would also let us rewrite some of the async ops GIO-style. The window for API cleanups and ABI breaks in these libraries is closing fast. We could at least rough in a common base class now with a private data section and get the ECal/EBook ABI break out of the way. Then add API to it later. I had the name "EClient" in mind for the base class: GObject | +-- EClient (implements GInitable) | +-- EBook | +-- ECal _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers