Re: [Evolution-hackers] Error Reporting in libebook
On Mon, 2009-01-19 at 14:10 +0100, Mathias Hasselmann wrote: > Some parts of the client API really need to be fixed. For instance > currently EContact cannot work reliably as EVCardAttribute is mutable. > Therefore you can change some contact attributes without EContact > noticing it. World would be much better if EVCardAttribute would be > immutable and if EVCard would have some virtual functions to inform > subclasses like EContact about added/removed attributes. I have a grand plan with very handwavy details which involves entirely replacing EVCard and EContact, extending the views API, and sanitising the book API. My shorter-term task list includes reviewing the Maemo patches, because yes this is a problem. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error Reporting in libebook
Am Montag, den 19.01.2009, 11:10 + schrieb Ross Burton: > On Mon, 2009-01-19 at 10:00 +0530, Srinivasa Ragavan wrote: > > Ross, didn't we break once before by stripping off some exposed bonobo > > stuff on the APIs ? So, is this new on the branch? > > The removal of exposed Bonobo interfaces was strictly speaking an API > break but didn't effect anyone because the functions which were removed > from the public API were impossible to call from outside > libebook/libecal. > > Adding GErrors to the client library would be a serious break for > clients, and something I'd personally defer until a full redesign of the > client APIs (something else I've been thinking about). Some parts of the client API really need to be fixed. For instance currently EContact cannot work reliably as EVCardAttribute is mutable. Therefore you can change some contact attributes without EContact noticing it. World would be much better if EVCardAttribute would be immutable and if EVCard would have some virtual functions to inform subclasses like EContact about added/removed attributes. Ciao, Mathias -- Mathias Hasselmann Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error Reporting in libebook
On Mon, 2009-01-19 at 10:00 +0530, Srinivasa Ragavan wrote: > Ross, didn't we break once before by stripping off some exposed bonobo > stuff on the APIs ? So, is this new on the branch? The removal of exposed Bonobo interfaces was strictly speaking an API break but didn't effect anyone because the functions which were removed from the public API were impossible to call from outside libebook/libecal. Adding GErrors to the client library would be a serious break for clients, and something I'd personally defer until a full redesign of the client APIs (something else I've been thinking about). Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error Reporting in libebook
On Fri, 2009-01-16 at 12:22 +, Ross Burton wrote: > On Fri, 2009-01-16 at 13:13 +0100, Matthias Braun wrote: > > I think it would be a good idea to have an additional API to report more > > details along the error messages. Do you agree with this? It's probably > > not optimal as you don't want translatable strings in evolution and > > can't even translate the messages returned by the server. I still think > > this would be way better than "Other Error". > > The DBus port will allow the server to send textual messages along with > the code, which I'd like to expose in libebook. > > Of course, if we're breaking API, then switching to GError would make > things a lot nicer. Ross, didn't we break once before by stripping off some exposed bonobo stuff on the APIs ? So, is this new on the branch? -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error Reporting in libebook
On Fri, 2009-01-16 at 13:13 +0100, Matthias Braun wrote: > I think it would be a good idea to have an additional API to report more > details along the error messages. Do you agree with this? It's probably > not optimal as you don't want translatable strings in evolution and > can't even translate the messages returned by the server. I still think > this would be way better than "Other Error". The DBus port will allow the server to send textual messages along with the code, which I'd like to expose in libebook. Of course, if we're breaking API, then switching to GError would make things a lot nicer. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Error Reporting in libebook
libebook currently has a set of predefined status codes which can be returned as a result to an operation (GNOME_Evolution_Addressbook_Success, GNOME_Evolution_Addressbook_RepositoryOffline, ...). This is fine to report most common problems. However at least in my ebook-webdav backend there are several situations which don't really match one of the predefined error codes. For example: - Another user has modified a contact while we were editing it: Uploading is not allowed anymore to not accidentally overwrite the changes. - The server is misconfigured and returns a bad mime-type after uploading a contact - The server reports access denied with a detailed error message (Example: "This server is down for maintenance and will be back online tomorrow. For emergencies call X") For the first 2 I can only report an "Other" error which will result in a completely useless error message for the user: "Error adding contact: Other error..." In the last I case the more detailed error message would be valuable additional info for the user. I think it would be a good idea to have an additional API to report more details along the error messages. Do you agree with this? It's probably not optimal as you don't want translatable strings in evolution and can't even translate the messages returned by the server. I still think this would be way better than "Other Error". Greetings, Matthias Braun ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
