Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
On Thu, 2015-02-19 at 07:43 +0100, Milan Crha wrote: On Wed, 2015-02-18 at 13:54 +0100, Patrick Ohly wrote: What I would prefer instead of the additional int parameter is a string-variant hash with a list of keys which can be extended in the future without breaking the API. Old clients not passing enough information then can either use reasonable defaults (when possible) or get an error telling the user to get his software updated. Hi, I would not do that this way. It would be horrible to call the function and create extra arguments for it in some sort of array and variants and so on. It's a pita to convert parameters forth and back when passing them through GDBus already, thus rather not add the same burden to the client functions too. I'm not convinced, but it's your project. However, I reserve the right to say told you so once the API needs to be changed the next time. I think that's better than causing old software unconditionally to not compile (due to a API change) or to not run (due to an ABI/soname change), because it keeps the option open to run some old software unchanged. I always understood that it's the soname version which is meant to cover these situations. Not that the two versions of eds can be installed in parallel in one prefix. But distro's typically don't do that because it's extra work to maintain two versions of the same software in parallel. It also would not work for EDS, because each client library is typically tightly coupled with a certain daemon version, and those cannot be installed or run in parallel. -- 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)
On Mon, 2015-02-02 at 17:25 +0100, Milan Crha wrote: Hello, I just committed a change, for 3.13.90 development version, into evolution-data-server [1], evolution [2], evolution-ews [3] and evolution-mapi [4], which moves authentication back to the clients. As discussed with Milan on IRC, I was worried that this change would break compatibility with SyncEvolution although SyncEvolution primarily (exclusively?!) is used with local storage, which works without authentication. I now looked further and found that SyncEvolution already works with the new EDS, despite the changed API (e_book_client_connect, e_cal_client_connect). That's because SyncEvolution opens an ESource with e_client_open(), which hasn't changed. SyncEvolution obviously won't work for sources which require authentication, but I don't think that'll be a big issue. [...] I have not looked at the concept in detail, but it looks reasonable at first glance. The other follow-up work will be to adapt any clients and libraries which might be affected by this change. I'd like to help as much as I'll be able, thus if there will be any issues spotted, feel free to ping me or drop me an email and I'll help you to migrate your code. I also removed all the old authentication code and functions, to avoid those system-modal prompts and basically all the old behavior users didn't like, the same as to cleanup API as much as possible. Bye, Milan [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=884fb8d872787d9 One comment that I already made on IRC: adding one additional int parameter to e_book_client_connect and e_cal_client_connect falls a bit short IMHO. I bet there will be some point in the future when some other new parameter will also be needed, causing another API break which could be avoided now. What I would prefer instead of the additional int parameter is a string-variant hash with a list of keys which can be extended in the future without breaking the API. Old clients not passing enough information then can either use reasonable defaults (when possible) or get an error telling the user to get his software updated. I think that's better than causing old software unconditionally to not compile (due to a API change) or to not run (due to an ABI/soname change), because it keeps the option open to run some old software unchanged. -- 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] custom labels
On Mon, 2014-05-26 at 07:38 +0200, Milan Crha wrote: On Sun, 2014-05-25 at 21:41 +0200, Patrick Ohly wrote: Instead if just the pre-defined Work, Home, Other, etc., the user can also enter arbitrary text. For example, instead of Other Tel: foo the user can enter Vacation Tel: bar for a telephone number that is to be used when that contact is in his vacation home. It's even more important for dates. There might be a lot more dates to be stored than just birthday and anniversary, so a repeating X-ABDate property is used with custom labels to allow that. Same for related persons. Hi, aha, I see, so it's more like TYPE parameter, with more fine-grained values. Would it be too complicated to use TYPE instead? So you mean something like TYPE=X-user entered string? The problem would be to distinguish between X-FOOBAR as a TYPE extensions and X-FOOBAR as user entered text. X-ABLabel avoids that by introducing a new parameter. It'll be slightly complicated for evolution's UI, but probably easier than dealing with it in a separate widget. I'm not sure whether this is easier for the UI. The whole EContact API deals poorly with arbitrary number of repeating properties. For some properties one can iterate over all of them (E_CONTACT_TEL), for others one can't (E_CONTACT_ADDRESS is documented as a single EContactAddress? Might be a documentation bug). For IM information it's definitely not possible to access arbitrary chat handles; the API only supports those for which a E_CONTACT_ADDRESS_service exists. -- 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] custom labels
On Fri, 2014-05-23 at 15:58 +0200, Milan Crha wrote: On Fri, 2014-05-23 at 14:56 +0200, Patrick Ohly wrote: I went ahead with the X-ABLabel as parameter approach. Hi, I'm sorry you didn't get any answer for this thread. I always forgot of it, also due to not having much opinion on the subject. I still do not fully understand what are the custom labels for. Is it a per-attribute property or a per-contact property? It feels like categories, if the later. What are the labels used for in UI? Instead if just the pre-defined Work, Home, Other, etc., the user can also enter arbitrary text. For example, instead of Other Tel: foo the user can enter Vacation Tel: bar for a telephone number that is to be used when that contact is in his vacation home. It's even more important for dates. There might be a lot more dates to be stored than just birthday and anniversary, so a repeating X-ABDate property is used with custom labels to allow that. Same for related persons. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: Hello, maybe you noticed that we have a GSoC project for this year, to enable introspection for calendar part of evolution-data-server (libecal), which will make it usable for other languages as well. As said already, doing this as add-on of libical and then later taking advantage of it in EDS seems like the right approach. Will is a student which will do the main work. The current problem is libical, its icalcomponent, enums and all other structures. I thought that we will be able to introspect this with simple boxed types, but it doesn't seem to be possible, thus the only option I can see is to massively change API of the calendar and define proxies for libical structures and enums. These proxies would be fully GObject-based, which might be a plus, I hope. I would, for example, define a GObject ICalComponent, which would have its i_cal_component_* API functions, mimic all the icalcomponent API, hiding the icalcomponent structure in the background. Would it be possible to keep the current EDS API around and just add the new introspectable API? Such change will be huge, but more importantly it'll be an earthquake for anything using libecal (the ECalComponent would not use icalcomponent anymore, it would start using ICalComponent instead). ECalComponent would use a proxy of the original icalcomponent, right? If the introspection layer in libical has a way to convert to and from the original icalcomponent and the introspectable proxy, then ECalComponent could convert back and forth as needed, depending on which API the EDS client uses. Because of this earthquake, I would like to hear from others their opinion. Maybe we overlooked some option in introspection (there is preferred to create introspection based on code annotations, not to define them by hand), but I'm afraid the most of the projects like SyncEvolution, whether it'll be able to handle such change gracefully. I've made my peace with ABI and API changes in EDS ;-} I'm not happy about them, but I can handle them with a combination of ifdefs and compilation of backend shared objects on different Linux distros. Just give me enough and explicit warning beforehand. If an API change can't be avoided, then don't let SyncEvolution hold you back. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] custom labels
On Fri, 2014-04-11 at 12:18 +0200, Patrick Ohly wrote: Hello! Both Google and Apple support custom labels for basically all of a contacts properties (telephone, email, address, instant messaging, etc). They use group tags to associate the extra label with the property: item4.ADR:;;custom address item4.X-ABLabel:custom-label Does anyone have suggestions for how this could and/or should be handled by EDS and Evolution? Obviously the Evolution UI would need to be modified to actually show the information. As a first step I would already be happy if the information didn't get lost during a import/edit/export cycle. I tried grouping, but when editing the field (an EMAIL in my test) its group tag was removed, thus breaking the connection to the custom label. After editing in Evolution: item1.X-ABLabel:foobar EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified I also tried a custom parameter, but that also got lost: EMAIL;X-ABLabel=foobar;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:email value - EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified I tried this with Evolution 3.4 (the one shipped with my current desktop, Debian Stable). Has perhaps anything been done regarding this in later versions? I am undecided about what EDS and Evolution should use internally to represent custom labels. I lean towards a custom parameter because although grouping is supported by EVCard, it hasn't been really used, has it? The concept of fields of interest would still work if the field also has the custom label as parameter (not that we have special support for anything other than UID and REV, but at least conceptually something else could also be supported). The custom parameter has one major drawback: it cannot store arbitrary string values. Line breaks and double quotes are not possible. The EDS vCard parser is also slightly broken and fails for X-ABRELATEDNAMES;X-ABLabel=domestic partner:domestic partner A space without quoting is valid according to http://tools.ietf.org/html/rfc2425#page-5 but e-vcard.c complains invalid character found in parameter spec and proceeds at the next line. On the other hand, deviating from the format of the peers will make interoperability harder. I'm not sure yet how I would do the conversion in SyncEvolution between X-ABLabel as parameter and X-ABLabel as property with group. Importing/exporting vCards manually also is affected by the choice of the internal format. Even if we used X-ABLabel + grouping, directly exchanging vCards with Apple will still not work properly due to the X-JABBER/AIM/... vs IMPP difference. Further work would be needed either way. I have not tested whether Apple understands X-AIM/JABBER/... instead of IMPP. I'm still undecided. A too complex X-ABLabel property value could be simplified to store it in a X-ABLabel parameter, but that'll drop user data. At this point it really would be good to get feedback from others. Is using groups going to be possible with EContact and Evolution or are we forced to use the simpler parameter approach, despite its limitations? Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Contacts database modifications history
On Wed, 2014-04-16 at 12:23 +0200, Milan Crha wrote: On Tue, 2014-04-15 at 13:16 +, Potrola, MateuszX wrote: I would like to have ability to receive some kind of notifications (or store information in some additional database) about modifications made to contacts database during synchronization. Hi, the compose of a diff for done changes is probably the hardest thing on this whole thing you'd like to achieve. There is always (at least) one place where this diff should be computed. I'm not much willing to add it into evolution-data-server itself, because it has no good use for it (at least not as of now). I tend to agree. It would be very hard to come up with a general purpose diff that works across a wider range of use cases. If it is configurable, the config language and implementation would have to be unnecessarily flexible (and thus complicated) for what Mateusz probably has in mind. I still think a plugin doing the diff would be okay. As Patrick pointed out, the previous implementation had sever issues which made the feature basically unusable. If we cannot make it done for all backends, then it probably might not be part of the evolution-data-server. We have a slightly different understanding of EDS here. You see EDS as an abstraction layer that offers just the functionality that can be implemented with all backends. We focus on EDS + local storage and try to make the best use of its capabilities, even if that means adding things to it which won't work with other backends. That's find, I think we can do both. It just means that whatever API gets added that only works with local storage needs to be clearly marked as local only in the documentation and/or there has to be a discovery mechanism for determining whether a certain EBookClient instance supports it. Anyway, I would prefer if you could create a plugin to SyncEvolution (does it support plugins?), also because it's the software you are targeting, not evolution-data-server code, Not necessarily. At the moment the focus is on cached PBAP address books that are only written by SyncEvolution, but that may change in the future. Perhaps someone wants to rip out SyncEvolution and do the caching differently, or wants to have address books that can be edited by the user. The change tracking still needs to work in those cases. Another argument for doing it inside EDS is that it can be combined with the actual sqlite database update. To me, that is the only bullet-proof way of ensuring that the change tracking information will be consistent with the actual content. This must work in a car, where the head unit can loose power at any moment. Ensuring that the sqlite database doesn't get corrupted is difficult enough. Ensuring that different processes get a chance to write different files will be even harder. I'd like to mention further use case for allowing hooks during the execution of EDS writes: this can be used to pre-compute data that is later going to be shown by a UI other than Evolution. I think EDS already does some of this for Evolution (like computing a full name) in a way that, strictly speaking, depends on the UI that is going to show the data. One even crazier idea was to maintain an on-disk data structure that can be memory-mapped to access contact data, including strings and their parsed photos ready to be displayed, without going through sqlite and all the string handling. I'm not a terribly big fan of that idea myself, but if there were hooks in EDS which could be used to track DB changes reliably, that would allow implementing this idea without further changes to EDS itself. Still, all this looks too complicated, adding unnecessary burden, consider that you specifically target SyncEvolution changes, thus why not to extend SyncEvolution to write its own backlog of done changes in some place, where your application may just read them from? SyncEvolution indeed does a read/update/write cycle when updating contacts. This would be a natural place to add a hook for such a plugin. Implementing it will be a bit tricky because it happens under the hood in the Synthesis sync engine, but I guess it could be done, if the alternative (a similar hook in EDS) is not acceptable. On Wed, 2014-04-16 at 09:02 +, Potrola, MateuszX wrote: What is the probability of failure of emitting signals ? The probability is close to 0. If it happens, then it's a bug in the backend (or the related code) and should be fixed as soon as discovered. The more likely failure is that EDS emits the change, but then the computer is shut down before the receiving side gets a chance to handle it = EDS DB was modified, change log in the receiver was not. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Contacts database modifications history
On Tue, 2014-04-15 at 13:16 +, Potrola, MateuszX wrote: In my project I’m using EDS as backend for storing contacts synchronized using Syncevolution. I would like to have ability to receive some kind of notifications (or store information in some additional database) about modifications made to contacts database during synchronization. What I mean by modification is information about contact id and list of contact’s fields that were modified (creation and removal of contact can be special case - list of all contact’s fields that are set will be returned). I know that current implementation of EBookView allows for something similar - it allows for detecting newly created, removed or modified contacts, but unfortunately it doesn’t provide details of modification. For those who were around at the time, there used to be a similar feature which recorded the UIDs of added, modified and removed contacts. It did not record individual changes and was not as configurable as Mateusz wants it to be now. I was on of those who argued in favor of removing that API because it had several design flaws: 1. Reading changes automatically destroyed the recorded changes, so one could not use it to just check whether something had been modified. 2. Changes were recorded for each client asking for it. EDS had no way of knowing whether the client was still interested in the changes and no garbage collection, so it ended up recording changes in perpetuity if the client was not given a chance (or forgot) to unregister. I wouldn't mind seeing a change tracking API getting re-added to EDS if these design flaws get addressed. If there is not enough interest in that, then a solution were such a feature can be added to EDS by a system integrator via plugins or conditional compilation would also satisfy Mateusz needs. I came up with two slightly different approaches how this could be achieved. First one is to create new address book backend (which will be inhering from file backend used by Syncevolution) and add there logic for calculating modifications when creating/modifying/removing contacts. These modifications will be stored in additional database, so some additional functions for handling this will need to be added to EBookSqlite class. Here are some pros and cons that I can see: Pros: - If someone don’t want to keep track of modifications history he can still use file backend - We can be sure that contacts database and modifications database will be in sync, by using attach function of sqlite (databases will be separated but transaction for modifying both of them will be treated as one transaction) Does it have to be a separate sqlite database? You could also use a new table directly in the sqlite datbase also used for the contact data. Cons: - Quite complex implementation, especially if some API needs to be exposed by EBookClient Perhaps the API for reading the changes could be limited to direct read access, potentially outside of the core libebook? Second solution is to extend current implementation of EBookView and add new signals like: contacts_added, contacts_modified, contacts_removed which will be providing ids and list of modified fields. Also new function for setting fields of interest will need to be added. Again in the address book backend implementation of logic for calculating modifications and emitting this signals will have to be added (it can be added to current file backend implementation or like in previous idea, new backend can be created based on file backend). Note that the EBookView could also be used as-is by doing the detailed check of what was modified in the receiving process. For new contacts it is very likely that the fields of interest were added, and updating contacts happens rarely enough that the overhead of sending updated data that then completely gets filtered out shouldn't matter. Pros: - Way of storing modifications information is up to the client application, - In our case we would like to know what modifications were made during synchronization, EDS is not aware of which modification of contacts are part of which synchronization, but client application has this knowledge. Cons: - We may end up with out of sync data in case if some signals will be not emitted. I see that as the most important reason why I would prefer the more integrated approach. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution Data Server] Locale change notification delayed
On Wed, 2014-02-12 at 15:27 +, Potrola, MateuszX wrote: Hi, Regarding your specific issue - it's probably working the same way in master as in the branch - my guess is that this is due to D-Bus property changes being delayed until the main loop is hit. It may be that a simple call to g_dbus_interface_skeleton_flush() inside the loop which sets locale on each book would fix this. You are right - it's the same on master branch, but adding g_dbus_interface_skeleton_flush call after setting locale fixes the issue. How I can submit patch, should I open new item on bugzilla and send it there? Yes, that's usually the best approach to ensure that patches get included in EDS. Please include patches that apply to master and the gnome-3-8-openismus branches. Please CC me and I can commit them (unless someone beats me to it - I am currently on vacation). Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libecal soname change
Hello! I just noticed that libecal bumped its soname to libecal-1.2.so.16 in EDS 3.10. The corresponding commit is: commit f30ae26320b359666b345c92405bf87f3f43250a Author: Matthew Barnes mbar...@redhat.com Date: Tue Jul 16 06:34:02 2013 -0400 Bump libecal / libedata-cal soname for API breaks. Matthew, can you elaborate what that break is? I've looked at a diff of the header files, but most of it is just reformatting. If there is an API break in there, then I missed it. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal soname change
On Thu, 2014-01-02 at 08:22 -0500, Matthew Barnes wrote: On Thu, 2014-01-02 at 11:30 +0100, Patrick Ohly wrote: I just noticed that libecal bumped its soname to libecal-1.2.so.16 in EDS 3.10. The corresponding commit is: commit f30ae26320b359666b345c92405bf87f3f43250a Author: Matthew Barnes mbar...@redhat.com Date: Tue Jul 16 06:34:02 2013 -0400 Bump libecal / libedata-cal soname for API breaks. Matthew, can you elaborate what that break is? The libdata-cal bump was to cover the preceding commits: [...] The libecal bump looks like it may have been a mistake on my part. I must have been under the impression the client-side API changed as well. Indeed, it looks like the soname change was unnecessary. It's too late to fix now, though. Can we perhaps agree on a different procedure for soname changes? If a patch requires a soname change, then alert the list here. Then interested developers can double-check whether a change really is necessary and/or whether a different solution can be found. In addition, the email will serve as warning about upcoming soname changes for developers (like me) who want to provide pre-compiled binaries. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plan to support and use vCard 4.0 (RFC 6350) in evolution-data-server
Hello! I only saw this email now - please copy me directly on emails that you want me to see. On Fri, 2013-05-17 at 15:34 +0200, Milan Crha wrote: Hello all, there was a little discussion about vCard 4.0, aka [RFC6350], which adds, among other things, a valuable KIND attribute, which is used to differentiate what the vCard is for. That would get rid of the evolution's X-EVOLUTION-LIST attribute, and maybe more. Here's a list of changes between 3.0 and 4.0 vCard [2]. The RFC is not that old yet, it's only from August 2011, but I guess it's not a problem. I'd like to know from others their opinion, whether it would be appreciated to switch to vCard 4.0 by default in evolution (-data-server). The plan is to keep backward compatibility with 3.0, even be able to save in 3.0 format (probably by some combo in a save dialog to pick the format user prefers), but otherwise switch internally into vCard 4.0. That way specialized editors could be created (as you know, there are currently only two, one for general contact, the other for contact list; maybe it'll make sense to introduce new contact editor for organization, room, and so on). In general I consider that a good thing. vCard 4.0 is a step forward, but it is not going to be adapted unless someone starts. But being the first to move forward will also mean that there will be problems exchanging data with peers that are still on vCard 3.0, simply because some information cannot be stored there. This is nothing new and SyncEvolution is prepared for such kind of format mismatches, it just will be some work to adapt it. In Evolution it would be good to have the ability to mark an address book as only supports vCard 3.0 properties. Such a flag should disable all UI features which rely on vCard 4.0. Then address books which mirror a remote vCard 3.0 address book will be usable without surprises for the user. I also do not know how will other programs work, when user would try to import a 4.0 vCard, while the program only knows 3.0. I believe the reading should not be strict on versions, the version only gives a hint what the card can, and what it should not, contain, right? One would hope so, but there's nothing in the standard requiring that. A client might also decide to play it safe and reject vCard 4.0 because it simply cannot know whether the vCard 3.0 decoding rules still apply. For example, in an early draft of vCard 4.0 the set of characters which needed quoting was defined differently than in 3.0. This was reverted back to the rules from 3.0 later on to enhance backward compatibility, but it might as well have stayed in the spec. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UI interaction from book/calendar backends
On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote: Actually I don't think evolution-source-registry requires GTK+. If it's the password dialog you're thinking of, we only link to gcr-base-3 which speaks via D-Bus to the process actually showing the password dialog. I'm not sure if evolution-source-registry is ultimately the right place for user interfaces, but I can't think of a better solution at present. I have a few requests, though: 1) Write this as a ESourceRegistryServer extension, and just link to GTK+ from the extension module. That way it's easily removable if the Tizen folks don't want it, or they want to implement their own version using Qt. Qt is so old-fashioned MeeGo - HTML5 rulez in Tizen! :- Thanks for keeping this in mind. I thing it is just good engineering and will hopefully also turn out to be useful outside of Tizen, which - just to avoid any confusion - does not use EDS at the moment and might never do. I'm bringing it up as an example of a distro where compiling EDS is hard at the moment because of the GTK dependency - there might be other, similiary limited platforms. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Addresbook query result ordering
On Mon, 2012-10-15 at 20:59 +0900, Tristan Van Berkom wrote: Secondly, I see three potential ways of approaching this problem and I wonder which way would be preferable. These are the possible avenues I'm aware of: a) Extend EBookQuery API This seems the most natural way to go about it, as I see it a query can contain multiple query terms and a single 'sort order' for the results; i.e. something like: e_book_query_set_order (query, EContactField, AscendingOrDescending); However, the EBookQuery does not contain multiple terms, instead it contains... multiple queries, which would make the API quite awkward since it would never make sense to have a query with more than one order defined for it's results. Modifying the query also has other drawbacks, it seems some backends like to send the serialized query expressions over the network, perhaps backwards compatibility would become a serious issue here (I've not investigated very far into this). b) A new set of query apis This might be the right choice considering drawbacks of 'a', in this case we could introduce an entirely new set of apis concerned with getting results from the addressbook. so methods such as: e_book_client_get_contacts (book, query, ...) would receive a complimentary: e_book_client_get_sorted_contacts (book, query, sort_field, ASCEND...) possibly deprecating all of the orderless apis which preceded these new apis along the way. This has the obvious disadvantage of implementation difficulty, i.e. EDS has still not been ported to use the new gdbus-codegen tool so all of that d-bus stuff would need to be done by hand (possibly less overall effort to just port to gdbus-codegen first). One upside to this is that backends which don't yet support the sorted results could fall back on existing APIs, possibly by introducing an EBookBackendSortable interface or such (question still would remain... how to advertise at runtime whether the sorting is supported by the active backend, perhaps via the 'capabilities' backend property). c) The least attractive and easiest way would be to simply add an api to EBookClient telling it in what order should you sort the addressbook (or, an ESourceExtension configuring the sort order). There is a forth option: d) add sorting to EBookView and leave e_book_client_get_contacts() as it is. Extending EBookView might be easier than extending EBookQuery. Note that when adding sorting, it also makes sense to add a maximum number of contacts parameter. Without sorting, that value is useless because is not predictable which contacts will be included in the result. With sorting, it becomes possible to populate a fixed-size view without having to receive all results. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
On Mon, 2012-10-08 at 14:42 -0400, Matthew Barnes wrote: Not sure if this fully addresses your question or not. I'm still at a bit of loss as to your use case. One example would be SyncEvolution, configuring and using additional features in EDS if and only if they are supported. If that cannot be detected at runtime, then one of several much less attractive workarounds must be used: * configure option in SyncEvolution - which users will get wrong * detect version of EDS and its backend (not even sure whether that works with enough granularity) and map to hard-coded list of capabilities - will be difficult to keep up-to-date -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding API breakage and lost test cases
On Tue, 2012-10-02 at 13:30 +0900, Tristan Van Berkom wrote: I'm still trying to find my footing here, the migration guide and new documentation on ESourceRegistry don't seem to outline how a new addressbook is actually created. i.e. if I wanted to test a specific addressbook backend, I would need a way to create one and populate it inside some sandbox directory. The location of the database files is fixed for the file backend. It has to be in ~/.local/share/evolution and is derived from the UUID. I agree that an explicit path property for the file backend would be nice. I'm getting as far as: // Create scratch source e_source_new_with_uid(); // Add it to the registry e_source_registry_new(); e_source_registry_add_sources(); // Fetch the new source from the registry (no longer 'scratch') e_source_registry_ref_source(); // Create the book now that we have a valid source (... or so we // suspected) e_book_new (); Problems I'm encountering are: a.) It seems that e_source_registry_ref_source() only finds the newly created source the next time I startup the test app (so this may indicate a bug, that the local registry is not updated after adding a new source). Not sure about that one. To some extend the API depends on processing D-Bus events in the main event loop. Perhaps that's not happening in your test app? b.) e_book_new() complains that the new source has no backend: e-book.c:2944: cannot get book from factory: No backend name in source 'Unnamed' You need to add the right extensions to the new source: source = e_source_new(); ESourceBackend *backend = e_source_get_extension(source, E_SOURCE_EXTENSION_ADDRESS_BOOK); e_source_backend_set_backend_name(backend, local); I'm sure I've missed something ridiculous here, while observing the sources e-data-book-factory.c, it seems that if the source were given an addressbook extension with the intended backend name... that it would happily go ahead and create a book. But, while we do have: e_source_get_extension() e_source_has_extension() I'm not seeing: e_source_add_extension() _get_extension() adds the extension implicitly. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Update on the composer port
On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote: Behavior of the editor is almost identical to GtkhtmlEditor, except for HTML mode - Plain text switching. GtkhtmlEditor is simply switching renderers on top of a single DOM document, but we can't do this with WebKit. I looked how others do it and ended up with a Switching to plain text will lose all formatting, OK? dialog. Please excuse my ignorance, but how will plain text mode work in the future? Will it still be possible to define item lists, indent blocks, etc.? I edit and send only plain text emails, but I use these formatting helps from Evolution, including saving of drafts with this markup. -- 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] e_cal_client_check_timezones() + e_cal_client_tzlookup() + Could not retrieve calendar time zone: Invalid object
Hello!
I've started testing a version of SyncEvolution which uses the
EBook/CalClient API. The import test fails for a VEVENT which uses a
custom timezone:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:EST/EDT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19671029T02
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19870405T02
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:20060416T205224Z-4272-727-1-251@gollum
DTSTAMP:20060416T205224Z
DTSTART;TZID=EST/EDT:20060406T14
DTEND;TZID=EST/EDT:20060406T143000
TRANSP:OPAQUE
SEQUENCE:2
SUMMARY:timezone New York with custom definition for 2006
CLASS:PUBLIC
CREATED:20060416T205301Z
LAST-MODIFIED:20120531T085920Z
END:VEVENT
END:VCALENDAR
e_cal_client_check_timezones() fails with Could not retrieve calendar
time zone: Invalid object. This comes from the attempt to look up
EST/EDT in an empty calendar:
icaltimezone *
e_cal_client_tzlookup (const gchar *tzid,
gconstpointer ecalclient,
GCancellable *cancellable,
GError **error)
{
...
if (e_cal_client_get_timezone_sync (cal_client, tzid, zone,
cancellable, local_error)) {
g_warn_if_fail (local_error == NULL);
return zone;
}
if (g_error_matches (local_error, E_CAL_CLIENT_ERROR,
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND)) {
/* We had to trigger this error to check for the
* timezone existance, clear it and return NULL. */
g_clear_error (local_error);
}
...
It's normal that e_cal_client_get_timezone_sync() fails. But it fails with an
unexpected error:
signal sender=:1.3 - dest=(null destination) serial=94
path=/org/gnome/evolution/dataserver/Calendar/1636/9;
interface=org.gnome.evolution.dataserver.Calendar; member=get_timezone_done
uint32 18
string org.gnome.evolution.dataserver.Calendar.InvalidObject
string Could not retrieve calendar time zone: Invalid object
string
Therefore the error is not cleared and e_cal_client_check_timezones()
aborts instead of accepting the EST/EDT time zone as it is.
This works in Evolution itself, probably because it let's the backend
itself do the e_cal_client_check_timezones() with a different lookup
function.
What is the preferred way of fixing this?
We could define that e_cal_client_get_timezone*() must return the
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND error when the time zone doesn't
exist and fix it to do so. Or we could make the error check in
e_cal_client_tzlookup() more liberal and ignore all E_CAL_CLIENT_ERRORs.
The latter might be easier, in particular considering that multiple
different calendar backends might need fixing to reliably return
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution module renames
On Fri, 2012-05-11 at 09:52 +0200, Milan Crha wrote: It's a general issue, because you never know what you'll have pulled in, and what steps you should do before you actually pull those changes in. I do not know if we can anyhow instruct autotools to not do this hard dependency of .am and .ac files, but I'm afraid we cannot do anything with this. --disable-maintainer-mode if you have AM_MAINTAINER_MODE in configure.ac. In general I don't trust make uninstall, in any project. It's usually not available when needed again, probably untested, or will fail for some other reason (like the one you found). I rather install into a directory that I can wipe out entirely, or use checkinstall. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: Which is the long-term vision for Evolution in this regard? Lack of proper offline support has been my main motivation for developing SyncEvolution. I know from others that they, too, would love to see this supported natively in EDS+Evolution, without the need for an external application. If there is sufficient interest, then I would be open for discussions about how SyncEvolution could be integrated seamlessly into Evolution. This would bring offline support for CalDAV, CardDAV, ActiveSync and might even add support for SyncML peers (client or server). But note that the current code is in C++ and depends on additional libraries that are not currently part of the GNOME stack (libsynthesis, libneon for offline CalDAV/CardDAV). Rewriting it in pure C+GNOME would be a lot of work. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] valgrind error in evolution-addressbook-factory + libdb
On Tue, 2012-03-06 at 14:33 +0100, Patrick Ohly wrote:
Hello!
Checking the EDS daemons from master under valgrind found this:
# ==23596== Conditional jump or move depends on uninitialised value(s)
# ==23596==at 0x9A404E7: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x9A41CB1: __log_put (in
/usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x9A42F2D: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x9A43D9F: __log_put_record (in
/usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x9986B1B: __ham_add_el (in
/usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x997E1FD: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x99F5548: __dbc_iput (in
/usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x99F314F: __db_put (in
/usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x9A04EBA: __db_put_pp (in
/usr/lib/x86_64-linux-gnu/libdb-5.1.so)
# ==23596==by 0x103CC953: do_create (e-book-backend-file.c:915)
# ==23596==by 0x103CCBFC: e_book_backend_file_create_contacts
(e-book-backend-file.c:988)
# ==23596==by 0x4E4AC31: e_book_backend_sync_create_contacts
(e-book-backend-sync.c:85)
# ==23596==by 0x4E4D3D7: book_backend_create_contacts
(e-book-backend-sync.c:493)
# ==23596==by 0x4E4ED2A: e_book_backend_create_contacts
(e-book-backend.c:465)
# ==23596==by 0x4E513D3: operation_thread (e-data-book.c:157)
# ==23596==by 0x83E9D07: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
# ==23596==by 0x83E77E5: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
# ==23596==by 0x8678B4F: start_thread (pthread_create.c:304)
# ==23596==by 0x896690C: clone (clone.S:112)
# ==23596== Uninitialised value was created by a stack allocation
# ==23596==at 0x994DB80: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
That is with libdb 5.1.29-1 from Debian Testing, in 64 bit mode.
At first glance it doesn't look like EDS can be causing this. I don't
have time to investigate by compiling libdb from source right now, but
at least I wanted to point out that there might be a cause for random
crashes.
It's not bad as I thought. Am I too pessimistic? ;-)
I've tracked it down and filed a bug against Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662917
From the report:
-
I've tracked the root cause in __ham_add_el() in src/hash/hash_page.c:
if (is_databig) {
doff.type = H_OFFPAGE;
===UMRW_SET(doff.unused[0]);
===UMRW_SET(doff.unused[1]);
===UMRW_SET(doff.unused[2]);
UMRW_SET is a NOP unless --enable-umrw is used during
configure. Compiling with --enable-umrw avoids the valgrind warning.
The unitialized value is used in a comparison of a checksum with 0.
I can convince myself that this is probably okay, because it doesn't
matter whether some of the data the checksum was calculated over
was uninitialized as long as it doesn't change later on.
But nevertheless, having to deal with such random valgrind errors
while debugging other code isn't nice. Please consider using
--enable-umrw when compiling libdb.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libebook master: obsolete vCard used despite updated properties
On Sat, 2012-03-03 at 13:26 +0100, Patrick Ohly wrote:
It removes the check for evc-priv-attributes. Adding that check back
fixes the problem.
Attached is the patch. I must admit that I'm not up-to-date about
release plans. From Matthew's email I gathered that there will be a
release on Monday?!
Please include this patch. I think it is obviously correct, or at least
as correct as the original code was before introducing the vCard 2.1
support - see below.
Question: why does the removed comment only mention UID? Isn't any
contact modification detected by checking evc-priv-attributes?
I'm still wondering about that, primarily because I want to be sure that
the code really works in all cases.
--
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.
From 956c91eb6e8ed89d3847738768d53752d2e2d7a4 Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Sun, 4 Mar 2012 14:24:03 +
Subject: [PATCH] EContact: fix parse vcard + update contact + commit
The commit which introduced vCard 2.1 encoding support (cca25e)
removed the evc-priv-attributes check. Without that check
the encoder will always return a cached vCard, even if the
EContact was modified in the meantime.
Found when updating of a contact with SyncEvolution's --update
operation failed because the UID set after parsing the vCard was
ignored and thus committing the update wasn't possible. Might also
break quite a lot of other functionality!
Fixed by addding the evc-priv-attributes in both cases (vCard 2.1
and 3.0).
---
addressbook/libebook/e-vcard.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/addressbook/libebook/e-vcard.c b/addressbook/libebook/e-vcard.c
index 1ff8af2..375a9d1 100644
--- a/addressbook/libebook/e-vcard.c
+++ b/addressbook/libebook/e-vcard.c
@@ -1251,12 +1251,14 @@ e_vcard_to_string (EVCard *evc,
switch (format) {
case EVC_FORMAT_VCARD_21:
- if (evc-priv-vcard strstr_nocase (evc-priv-vcard, CRLF VERSION:2.1 CRLF))
+ if (evc-priv-vcard evc-priv-attributes == NULL
+ strstr_nocase (evc-priv-vcard, CRLF VERSION:2.1 CRLF))
return g_strdup (evc-priv-vcard);
return e_vcard_to_string_vcard_21 (evc);
case EVC_FORMAT_VCARD_30:
- if (evc-priv-vcard strstr_nocase (evc-priv-vcard, CRLF VERSION:3.0 CRLF))
+ if (evc-priv-vcard evc-priv-attributes == NULL
+ strstr_nocase (evc-priv-vcard, CRLF VERSION:3.0 CRLF))
return g_strdup (evc-priv-vcard);
return e_vcard_to_string_vcard_30 (evc);
--
1.7.2.5
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libebook master: obsolete vCard used despite updated properties
Hello!
I tested SyncEvolution against current EDS master and found a problem:
setting a UID before committing an updated contact has no effect.
The sequence of events is this:
1. e_contact_new_from_vcard() where the vCard contains no UID.
2. e_contact_set(E_CONTACT_UID, uid) - g_object_set()
3. e_book_commit_contact() - e_vcard_to_string() - D-Bus
In step 3, e_vcard_to_string() returns the cached evc-priv-vcard
without the UID although it has a UID in its attributes
(evc-priv-attributes).
I think the culprit is this commit here:
commit cca25e98a71d8c06f9ce1b53658ec4675f2dd5c2
Author: Bartosz Szatkowski bulis...@linux.com
Date: Tue Oct 18 12:29:07 2011 +0200
Bug #656603 - Add support for generating vCard 2.1 in libebook
[...]
@@ -1016,17 +1246,16 @@ e_vcard_to_string (EVCard *evc,
{
g_return_val_if_fail (E_IS_VCARD (evc), NULL);
- /* If the vcard is not parsed yet, and if we don't have a UID in
priv-attributes
- return priv-vcard directly */
- /* XXX: The format is ignored but it does not really matter
-* since only 3.0 is supported at the moment */
- if (evc-priv-vcard != NULL evc-priv-attributes == NULL)
- return g_strdup (evc-priv-vcard);
-
switch (format) {
case EVC_FORMAT_VCARD_21:
+ if (evc-priv-vcard strstr_nocase (evc-priv-vcard, CRLF
VERSION:2.1 CRLF))
+ return g_strdup (evc-priv-vcard);
+
return e_vcard_to_string_vcard_21 (evc);
case EVC_FORMAT_VCARD_30:
+ if (evc-priv-vcard strstr_nocase (evc-priv-vcard, CRLF
VERSION:3.0 CRLF))
+ return g_strdup (evc-priv-vcard);
+
return e_vcard_to_string_vcard_30 (evc);
default:
g_warning (invalid format specifier passed to
e_vcard_to_string);
It removes the check for evc-priv-attributes. Adding that check back
fixes the problem.
Question: why does the removed comment only mention UID? Isn't any
contact modification detected by checking evc-priv-attributes?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] PHOTO uri + escaping
Hello! I am seeing an issue where the Synthesis engine doesn't parse a vCard with PHOTO;VALUE=uri the same way as libebook's e_contact_inline_local_photo() does. The vCard has: PHOTO;VALUE=uri:file:///home/nightly/.local/share/evolution/addressbook/130 3826927.6946.21@mob-sync2/photos/pas_id_4F511ADB000F_photo-file0.image %252FGIF The actual file name is: /home/nightly/.local/share/evolution/addressbook/1303826927.6946.21@mob-sync2/photos/pas_id_4F521E7A000F_photo-file0.image%2FGIF Note that %2FGIF was encoded as %252FGIF in the vCard. The Synthesis engine does no decoding of the %25 before trying to read the file. I think this is a bug, and I take full credit, eh, blame for it as I added that too simplistic URI handling code ;-) However, why does the file name end in %2FGIF in the first place? It would be much more readable to just use .GIF. That notwithstanding, of course I intend to fix the bug in the Synthesis engine. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libecal: memory leak
Hello! I've updated one of the chroots for SyncEvolution's nightly testing to current Debian Testing. Now I am seeing a memory leak in libecal 3.2.2: ==23530== 597 bytes in 15 blocks are definitely lost in loss record 4,401 of 4,550 ==23530==at 0x4C27673: malloc (vg_replace_malloc.c:263) ==23530==by 0x7D8AC02: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x7DA13BD: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x13BF5CCF: gdbus_proxy_async_method_done (e-gdbus-templates.c:1016) ==23530==by 0x78F7803: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7909789: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912E10: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912FB1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x13BF5438: e_gdbus_proxy_emit_signal (e-gdbus-templates.c:600) ==23530==by 0xC5BE7BB: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.5.0.10) ==23530==by 0xC5BE236: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.5.0.10) ==23530==by 0x78F7CC6: g_cclosure_marshal_generic (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x78F7803: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x79095BE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912E10: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912FB1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0xB82F0FE: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3000.2) ==23530==by 0xB81D9AD: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3000.2) ==23530==by 0x7D840CE: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x7D848C7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x7D84A98: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x13BF36EA: gdbus_proxy_call_sync (e-gdbus-templates.c:1442) ==23530==by 0x13BF72B8: e_gdbus_proxy_call_sync_string__string (e-gdbus-templates.c:1608) ==23530==by 0x1650896A: e_gdbus_cal_call_create_object_sync (e-gdbus-cal.c:571) ==23530==by 0x164DEE15: e_cal_create_object (e-cal.c:3932) ==23530==by 0xFA0B881: SyncEvo::EvolutionCalendarSource::insertItem(std::string const, std::string const, bool) (EvolutionCalendarSource.cpp:446) Does that look familiar to anyone? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal/book_open() + only_if_exists
On Tue, 2012-02-14 at 08:45 +0100, Milan Crha wrote: On Mon, 2012-02-13 at 21:52 +0100, Patrick Ohly wrote: * A second invocation of SyncEvolution finds the definition of the system address book via e_book_get_addressbooks() and tries to open it with e_book_open(only_if_exists=false), which then fails with various errors, depending on the EDS version (Cannot open book: db error 0x2 (No such file or directory) in 3.2, DB_RUNRECOVERY in 3.3). The problem can be avoided by always passing only_if_exists=true to the open calls. The way how the API is defined and/or implemented, creating an database definition and creating the actual database files are two different steps. Hi, that's rather a bug in the backend. Calling with only_if_exists=false might mean that the backend should create a new book/calendar, in case it's not available yet. Otherwise, if you call with only_if_exists=true, the backend should claim an error when the requested book/calendar cannot be opened. Sorry, typo in my email. I meant the problem can be avoided by always passing only_if_exist=false. In other words, never use only_if_exists=true because it serves no useful purpose. Is that correct or is there some legitimate usage for only_if_exists=true? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] e_cal/book_open() + only_if_exists
Hello! With EDS 3.2 and 3.3 I've seen the following problem on a clean account (no databases, no gconf keys): * An invocation of SyncEvolution to list databases calls e_book_new_system_addressbook(), which creates a gconf /apps/evolution/addressbook/sources entry for the system address book. * A second invocation of SyncEvolution finds the definition of the system address book via e_book_get_addressbooks() and tries to open it with e_book_open(only_if_exists=false), which then fails with various errors, depending on the EDS version (Cannot open book: db error 0x2 (No such file or directory) in 3.2, DB_RUNRECOVERY in 3.3). The problem can be avoided by always passing only_if_exists=true to the open calls. The way how the API is defined and/or implemented, creating an database definition and creating the actual database files are two different steps. Therefore a client can never be sure whether a database really exists, and thus it always to pass only_if_exists=true. If that is the case, then why have it at all? We might as well ignore the value in the current implementations and mark it as deprecated in the APIs. Or do I miss something? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] History is gone after wip/gsettings branch merge
On Mon, 2011-11-28 at 08:27 +0100, Milan Crha wrote: Hi, I just realized a very sad thing, the history of certain files is gone after the merge of wip/gsettings branch into evolution master. I tried both gitk and git log on mail/e-mail-session.c and the history is ending on October 6th, 2010. I had a copy of the git repo before that merge and the history of that file also ended on that date. I doubt that this has anything to do with any git merge. The question is: Can this be fixed? Very hard. Most likely the initial conversion from svn was incomplete. One could redo the conversion and/or rewrite the history, but that implies all commits done later and all trees that other people currently work with become invalid and need to be rebased. IMHO it would be better to add the missing history as independent branches. P.S.: I never trusted the git merge, it breaks many things, from commit times/dates Huh? How that? git merge only adds one commit. It does not rewrite existing commits from any of the branches that get merged. to lost work from others if the merger is not careful enough. Now that is indeed a valid concern. A git merge is like applying a single, fairly complex patch (assuming that the branch which gets merged is large). To be on the safe side, a merge could be prepared, pushed to a separate branch and then get reviewed before fast-forwarding the real branch. The downside is that any change on the real branch in the meantime requires redoing the merge or accepting some kind of unreviewed merging again: merge A+B = C gets reviewed, A' + C does not, which might be okay if the delta between A and A' is small and does not lead to further conflicts with C. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] History is gone after wip/gsettings branch merge
On Mon, 2011-11-28 at 10:59 +0100, Milan Crha wrote: On Mon, 2011-11-28 at 10:15 +0100, Patrick Ohly wrote: On Mon, 2011-11-28 at 08:27 +0100, Milan Crha wrote: Hi, I just realized a very sad thing, the history of certain files is gone after the merge of wip/gsettings branch into evolution master. I tried both gitk and git log on mail/e-mail-session.c and the history is ending on October 6th, 2010. I had a copy of the git repo before that merge and the history of that file also ended on that date. I doubt that this has anything to do with any git merge. Hrm, is it? Actually I now doubt that my git repo was old enough. I thought you talked about the account settings, which is the one which I hadn't pulled yet. Either way, a git merge doesn't rewrite history. I know it's a new file, but I thought it's older than October 6th, 2010. It seems that a06e4484b on October 6th, 2010 renamed and modified the file (mail-session.c - e-mail-session.c) at the same time. That defeats git's --follow and --find-renames heuristics. That's actually an argument in favor of doing merges instead of just applying the final, resulting patch: the file renaming can be committed in a single commit together with the related changes (autotools, include statements) without changing the file content itself. Then in a separate commit, make the actual changes to the content. That is easier to review (because the diffs will be much smaller) and I bet that git log would be able to show the full history for the renamed file. Very interesting discussion :-) SyncEvolution almost never accepts new features via merging, instead applying the final, squashed patch. The argument was that a linear development history is easier to read. But it does have this disadvantage of not handling rename+modification and also looses valuable history about the patch itself, or at least makes it harder to find. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UID in vCard
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly: Hello! [...] On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: If a new UID is to be created, it is the responsibility of the Kolab client to assign one. The Kolab server itself is unaware to object UIDs and will not touch them (no read/write/anything). With client, I meant an EDS client here (= the application using libebook). That there is a Kolab client and server involved is of course important for you, but not so much for a user of the abstract libebook API ;-) While the E-D-S client (like Evo) might not be interested whether it is a Kolab backend being used, there is still one thing you may wish to consider here. We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our backend. That should never be necessary. As you said, having such two different ids doesn't buy the user much. Only a radical step away from do what you want with UID to UID must be UUID and preserved will - not realistic anytime soon, but at least a proof-of-concept would be nice. That is the whole point of this mail thread: a vCard UID may have a meaning outside of the storage in which it currently exists. EDS cannot know whether that is the case. Currently it assumes that the UID has no meaning and throws it away when adding contacts. Not globally true. The file backend may do so, but it is the backend implementation deciding whether re-writing a UID or not. E-D-S cannot decide that, since it does not know what a given backend is dealing with. What I meant is the Evolution/EDS API expectation that adding a contact will never fail because of a UID conflict. Whether the backend implements that by always overwriting the UID (as the file backend does) or by keep it when possible and overwriting otherwise (as in the Kolab backend) is indeed a backend implementation detail. But it has the same effect: a libebook user cannot reliably detect an add-add UID conflict. It can check for a contact with the UID first (by assuming that ID in the libebook API == UID in vCard), but then there's still a race condition between that check and creating that contact. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UID in vCard
Hello! Before I reply to Christian, let me elaborate a bit more on why overwriting the UID is bad for syncing. I thought it was obvious, but probably not ;-} What I have in mind is a system where contact data moves freely and ad-hoc between peers, without being forced to go through a central server, stick to a fixed topology or use a specific database technology. This cannot be done with today's technology because avoiding duplicates becomes unreliable. CouchDB comes close, but is a closed system. You also cannot create two independent CouchDB instances and then merge them (at least that is my understanding - I might be wrong on that particular aspect). A creator-assigned global UID would be the right way of solving this. Storages or systems which do create and preserve such a UID cannot participate in that system. I'd like to make sure that the EDS file backend can be part of it, even if it is just for experiments. For more details, see the TODOs on ad-hoc synchronization in http://syncevolution.org/blogs/pohly/2011/state-union-version-12 On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: [...] Just adding a few bits on how the situation is for the Kolab groupware server. The evolution-kolab backend cannot ask the Kolab server for a UID (since there is no API for that) nor does the server enforce certain UIDs on a PIM object (but, of course, that there be one). The only requirement is that the PIM object's UID be unique in a given PIM folder. If the UID is globally unique, all the better. That's the same situation as with the file backend then: a client could decide to set a UID in the vCard before creating the contact, and the Kolab backend+server would use that UID instead of creating their own. Good :-) If a new UID is to be created, it is the responsibility of the Kolab client to assign one. The Kolab server itself is unaware to object UIDs and will not touch them (no read/write/anything). With client, I meant an EDS client here (= the application using libebook). That there is a Kolab client and server involved is of course important for you, but not so much for a user of the abstract libebook API ;-) How does the backend work at the moment? Does it always overwrite an existing UID like the file backend does or does it already work as I proposed? Existing UIDs are (and must be) preserved. This is a requirement for Kolab client interop, since they all rely on the object's UID to reference it (especially regarding changes to the contents of the PIM object). In Kolab, there is no way to correctly reference an object other than using its UID. If it does, do you throw a E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not unique? Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some like to call just plain old here =). No error message in that case. If the UID already exists, it gets rewritten. It was a tradeoff here - an existing Kolab object and its UID superseedes a new one. Imported objects are regarded as new (being assigned a new UID), should the UID they carry already exist in the given PIM folder. The original UID would do no good in the Kolab context if another object with that same UID already exists, since other groupware clients do have an idea about the object this UID refers to already. Trying to find out whether the imported object could actually be an update for an already existing one seemed too complex and out-of-scope for the initial evolution-kolab implementation. We're now porting to current Evo/EDS git master, but I would still keep the current implementation unchanged when it comes to how to interpret UIDs of imported objects. That is the whole point of this mail thread: a vCard UID may have a meaning outside of the storage in which it currently exists. EDS cannot know whether that is the case. Currently it assumes that the UID has no meaning and throws it away when adding contacts. Consider sending around vCard with globally unique UID. A user might import that vCard once into Kolab using Kolab client A. Then when he tries again with Kolab client B, the client can warn him reliably that this particular contact was already imported. PIM objects already residing on the Kolab server do carry a UID, created by the client which created the object (evolution-kolab, Kontact, Horde, Outlook with a Kolab connector, Thunderbird via Lightning/SyncKolab, ...). Do you attempt to make the UID globally unique, for example by using a UUID? In our current implementation, the UID will be unique to the Kolab server at hand. Since the Kolab server does not impose specific restrictions on the format of the UID, evolution-kolab could change the UID generation code (we currently use E-D-S
Re: [Evolution-hackers] UID in vCard
On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: Hi everyone, Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha: On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: So I suggest to pursue the first approach instead. I think it is possible for the file backend. Is it also possible for other backends? Or are some unable to store the UID and look up contacts (efficiently) by it? In that case we will have to relax the semantic of the API and accept that some backends still use their own local ID. Supports UID should be defined as a capability of the backend so that clients can take it into account. Hi, I wouldn't call it local UID, it's rather backend's UID and mostly not, this is not doable for groupware backends which are using server-supplied unique identifiers for contacts/calendars, like message IDs in evolution-mapi, which talks to Exchange servers. It's easier, and makes sense, to use server-side IDs, which are meant to be unique. It's also a reason, from my point of view, why e_data_book_respond_create_contacts() passes UIDs of newly created objects back to the client. [...] Just adding a few bits on how the situation is for the Kolab groupware server. The evolution-kolab backend cannot ask the Kolab server for a UID (since there is no API for that) nor does the server enforce certain UIDs on a PIM object (but, of course, that there be one). The only requirement is that the PIM object's UID be unique in a given PIM folder. If the UID is globally unique, all the better. That's the same situation as with the file backend then: a client could decide to set a UID in the vCard before creating the contact, and the Kolab backend+server would use that UID instead of creating their own. Good :-) How does the backend work at the moment? Does it always overwrite an existing UID like the file backend does or does it already work as I proposed? If it does, do you throw a E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not unique? PIM objects already residing on the Kolab server do carry a UID, created by the client which created the object (evolution-kolab, Kontact, Horde, Outlook with a Kolab connector, Thunderbird via Lightning/SyncKolab, ...). Do you attempt to make the UID globally unique, for example by using a UUID? When it comes to importing a PIM object, it is not possible to retain its UID in the cases where the same UID exists on the server already for another PIM object (unlikely, but possible, since Kolab object UIDs are not required to be globally unique). As long as we're in offline mode, we may at first succeed retaining the object's UID, but when going online any syncing with the server, find that a new UID must be set on the object. What happens during syncing? Do you resolve the add-add conflict by duplicating the item, merging them or discarding one copy? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UID in vCard
On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote: On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: So I suggest to pursue the first approach instead. I think it is possible for the file backend. Is it also possible for other backends? Or are some unable to store the UID and look up contacts (efficiently) by it? In that case we will have to relax the semantic of the API and accept that some backends still use their own local ID. Supports UID should be defined as a capability of the backend so that clients can take it into account. Hi, I wouldn't call it local UID, it's rather backend's UID I wouldn't use the term UID at all for this local (or backend) ID. UID has a specific meaning for both iCalendar 2.0 (where it is well-defined) and vCard (where it is less well-defined). Introducing yet another flavor of UID just leads to confusion, in particular when the same contact has both the original vCard UID and a local backend UID. and mostly not, this is not doable for groupware backends which are using server-supplied unique identifiers for contacts/calendars, like message IDs in evolution-mapi, which talks to Exchange servers. It's easier, and makes sense, to use server-side IDs, which are meant to be unique. It's also a reason, from my point of view, why e_data_book_respond_create_contacts() passes UIDs of newly created objects back to the client. So we do need the concept of local IDs which are not the same as the creator-assigned UID. What about a CardDAV server? It has server-supplied IDs (the path to the resource) and a UID as part of the vCard stored there? How is that handled at the moment? And what does that mean for the file backend? I still think it would be good if the file backend supported creator-assigned UIDs. That other backends can't do that doesn't mean that file backend is not allowed to do it, right? For example with Google calendar, which is served by CalDAV backend, the backend fetches newly added event from the server only to present UI with real object from the server, because the server can modify the event on its own when creating it (it adds default alarms, if set in Google's calendar preferences on the Web). Are you saying that Google Calendar EDS does *not* report the original iCalendar 2.0 UID? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
On Mi, 2011-09-14 at 08:28 +0200, Milan Crha wrote: yes, I agree, it wasn't the right change, I'm sorry for that. Please revert the commit and reopen the bug. I reverted the EXDATE part of the commit, but couldn't reopen the bug (Bugzilla does't offer me that option). Can you reopen it? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
On Mo, 2011-09-12 at 09:09 +0200, Patrick Ohly wrote: On Mo, 2011-09-12 at 07:56 +0200, Milan Crha wrote: On Fri, 2011-09-09 at 10:32 +0200, Patrick Ohly wrote: Milan, can you shed some light on why the patch solves #655253? I fail to see what e_cal_backend_file_modify_object() has to do with deleting one occurrence of a repeatable event. If the EXDATE was really necessary to avoid having the original and the detached recurrence show up, then IMHO adding the EXDATE only works around the real problem. The real problem is more likely to be in the matching against RECURRENCE-ID. Hi, sure, the thing why I added it there is that when you move one instance of a recurring event to another hour, then you are asked whether you want to change time for all instances or only this instance. Moving only this instance should create a detached instance, and create an exception in the master object. No, creating the exception is not necessary. Suppose you have a VEVENT with RRULE which expands to a regular start time of one recurrence at, say, 20110912T09Z. Then the detached recurrence must have RECURRENCE-ID:20110912T09Z and it will *replace* the regular recurrence without having to add an EXDATE to the parent. That's part of the iCalendar 2.0 semantic. The root cause of the bug is that the detached recurrences, if created with current Evolution master, do not get the same UID as the original recurring event. I've verified that by looking at the resulting .ics file. It works correctly in 2.32.4. Does anyone know where in the 3.x cycle this broke? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
On Di, 2011-09-13 at 17:59 +0200, Patrick Ohly wrote:
On Mo, 2011-09-12 at 09:09 +0200, Patrick Ohly wrote:
On Mo, 2011-09-12 at 07:56 +0200, Milan Crha wrote:
On Fri, 2011-09-09 at 10:32 +0200, Patrick Ohly wrote:
Milan, can you shed some light on why the patch solves #655253? I fail
to see what e_cal_backend_file_modify_object() has to do with deleting
one occurrence of a repeatable event.
If the EXDATE was really necessary to avoid having the original and the
detached recurrence show up, then IMHO adding the EXDATE only works
around the real problem. The real problem is more likely to be in the
matching against RECURRENCE-ID.
Hi,
sure, the thing why I added it there is that when you move one instance
of a recurring event to another hour, then you are asked whether you
want to change time for all instances or only this instance. Moving only
this instance should create a detached instance, and create an exception
in the master object.
No, creating the exception is not necessary.
Suppose you have a VEVENT with RRULE which expands to a regular start
time of one recurrence at, say, 20110912T09Z. Then the detached
recurrence must have RECURRENCE-ID:20110912T09Z and it will
*replace* the regular recurrence without having to add an EXDATE to the
parent. That's part of the iCalendar 2.0 semantic.
The root cause of the bug is that the detached recurrences, if created
with current Evolution master, do not get the same UID as the original
recurring event. I've verified that by looking at the resulting .ics
file.
It works correctly in 2.32.4.
Does anyone know where in the 3.x cycle this broke?
Darn, I can no longer reproduce the problem. I was able to reproduce
with the source from current master (thus my statement above about the
UIDs not matching), but after removing the EXDATE code it all works
fine: same UID, no duplicates shown even after restart. Even after
restoring the original source it still works (same UID, EXDATE added).
Milan, do you agree that the e_cal_util_remove_instances() call can and
should be removed? Either way, it only works around whatever is causing
the UID issue. Adding the EXDATE just pampers over that problem and
still doesn't fix things like remove all recurrences.
Patch is here:
diff --git a/calendar/backends/file/e-cal-backend-file.c
b/calendar/backends/file/e-cal-backend-file.c
index 2dc9a90..e1cfbb3 100644
--- a/calendar/backends/file/e-cal-backend-file.c
+++ b/calendar/backends/file/e-cal-backend-file.c
@@ -2391,9 +2391,6 @@ e_cal_backend_file_modify_object (ECalBackendSync
*backend,
priv-comp = g_list_remove (priv-comp, recurrence);
obj_data-recurrences_list = g_list_remove
(obj_data-recurrences_list, recurrence);
g_hash_table_remove (obj_data-recurrences, rid);
- } else if (obj_data-full_object) {
- /* add exception for the modified instance */
- e_cal_util_remove_instances
(e_cal_component_get_icalcomponent (obj_data-full_object), icalt
}
/* add the detached instance */
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)
Hello!
I have started integrating a patch by Chris Dumez which switches the
SyncEvolution Evolution API from the legacy API to the new EClient API
in EDS 3.2.
I'm currently testing it in the nightly testing, with EDS compiled from
source on Debian Unstable. Backend is the normal file backend.
I see one regression: when adding a detached recurrence with
e_cal_client_modify_object_sync(CALOBJ_MOD_THIS), an EXDATE is added to
the parent event.
While semantically correct as far as I know (the detached recurrence
overrides the EXDATE, instead of the EXDATE canceling out the detached
recurrence), it is a side effect which makes it hard to undo the
addition of the detached recurrence. Calling
e_cal_remove_object_with_mod(CALOBJ_MOD_ONLY_THIS) won't be enough, the
caller would also have to know that it has to remove the EXDATE.
It also breaks SyncEvolution's automated testing:
http://syncev.meego.com/latest/head-unstable-amd64/5-evolution/Client_Source_eds_event_LinkedItems_0_testLinkedItemsParentChild.log
This seems to come from this code:
e_cal_backend_file_modify_object()
8631a8f2 (Milan Crha 2011-09-02 13:21:07 +0200 2394) } else
if (obj_data-full_object) {
8631a8f2 (Milan Crha 2011-09-02 13:21:07 +0200 2395)
/* add exception for the modified instance */
8631a8f2 (Milan Crha 2011-09-02 13:21:07 +0200 2396)
e_cal_util_remove_instances (e_cal_component_get_icalcomponent
(obj_data-full_object), icaltime_from_string (rid), CALOBJ_MOD_THIS);
commit 8631a8f2e0c1ca71a48aeca5a44a11506ac77e33
Author: Milan Crha mc...@redhat.com
Date: Fri Sep 2 13:21:07 2011 +0200
Bug #655253 - Delete of one occurrence of a repeatable event don't work
This was added in 3.1.91.
Milan, can you shed some light on why the patch solves #655253? I fail
to see what e_cal_backend_file_modify_object() has to do with deleting
one occurrence of a repeatable event.
If the EXDATE was really necessary to avoid having the original and the
detached recurrence show up, then IMHO adding the EXDATE only works
around the real problem. The real problem is more likely to be in the
matching against RECURRENCE-ID.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
On Fri, 2011-07-08 at 14:45 -0400, Tristan Van Berkom wrote: However the EContact passed to e_book_commit_contact() will not be modified by the call to the backend (the gdbus call simply queues a job in the addressbook thread and returns)... so for the caller to get the real uri one must further call e_book_get_contact() or have an EBookView in play to receive it. I don't think EDS ever made the promise that an items would be saved exactly as sent. Apps which need an exact copy of the stored item indeed should use a view to get the real content of the database after requesting changes. Perhaps the backend needs to claim that it supports a list of protocols for staging data (such as 'file','http','ftp' etc) ? The staging dir would be, by definition, local. I don't think we should support anything else. Ah I had imagined it the other way around (that the addressbook would take care of downloading any data from a client's directory). This is also what I had in mind. But it seems more practical to leave file uploading to the client, We can design the API to make that possible, but I don't think we should worry to much about it now. All in all then the added code I think would be: o An api for a client to get a staging directory (which can return NULL) const gchar *e_book_get_staging_uri (); The api would be implemented with a new GDBus method call or property which would in turn be handled by EDataBook. EDataBook would implement it in a backend specific way and return NULL if the backend does not implement the new -get_staging_uri() vfunc. o EBookBackendFile (the BDB addressbook backend) will then manage a staging directory and implement the new vfunc: EBookBackendClass-get_staging_uri() to report the file://path/to/staging/directory/ Managing the staging directory will only consist of creating it at book creation time, removing it at book remove time and emptying it out every time the book is freshly opened (just in case). Do we want one staging directory per address book, or one staging directory per client? My proposal was to create one per client, because then client's don't have to worry about file name collisions (they are the only ones writing into it) and files can be deleted once the client exits. If we have a long-running user of the address book (like Evolution) and a short-lived one (like SyncEvolution) and only one staging directory, then files created and not properly committed by SyncEvolution cannot be cleaned until also Evolution quits. It might also be advantageous to have one directory per client process once MeeGo adds separate privileges for processes running under the same user ID. This is currently a pie in the sky, though. Note that the private staging directory is a bit at odds with allowing arbitrary URIs. While such a guarantee is easy for local directories, it might make less sense for other URIs (like HTTP resources + PUT). This could be resolved by making the guarantee only for file:// URIs. o The local file backend will then move files from the staging directory to the 'photos' directory and update the uris in the stored vCards (whenever receiving vCard updates that refer to files in the staging uri). If the addressbook receives uris in the staging directory which have failed to upload or do not exist for any reason that will be considered an error (the client needs to finish uploading successfully before sending vcards holding staged uris of course). Clients can then try to get a staging uri, if they receive a staging uri then they should check if they support the protocol. If the backend returns an ssh:// staging directory and the client cannot deal with that, then the client should fall back to sending binary blobs (whether or not there is a staging directory available, clients can continue to send photo data as binary blobs reliably anyway). In theory clients can deal with the addressbook owned staging uri pretty conveniently using GIO to check if the staging uri is supported and to upload data. Perhaps this is not so very complex after all ? I think it is doable. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
On Fri, 2011-07-08 at 10:42 +0100, Burton, Ross wrote: On 7 July 2011 09:48, Patrick Ohly patrick.o...@gmx.de wrote: At any rate, if it's judged that the performance gain of using a staging directory is worth the added complexity then let's do it. I'd like to hear some other opinions about this. Ross? It does sound like a lot of extra complexity and complication for the performance gain... So what do you suggest? Inline the data when storing a photo and strip it out in the backend? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
On Thu, 2011-07-07 at 20:54 -0400, Tristan Van Berkom wrote: It's possible but will need to be conditional, probably depending on whether there is a staging directory available or not. I'll start thinking about how this staging directory could be implemented, I suppose the client needs to create one somehow while opening the EBook, and only on the condition that the backend can handle incoming data from a staging directory. The EDS daemon needs to create the directory. That's required for the cleanup rules to work. I would do it in the backend, possibly with some server-side utility code that can be used by multiple backends. Possibly at book creation time one needs to specify an actual directory for this (or has the option to specify a directory)... The backend should choose. That way it can pick something that is suitable (like on the same filesystem) without exposing implementation details to the client. How do remote backends handle uris from the local staging dir ? They'll simply refuse to create a staging directory and thus request that the client continues to inline data. perhaps the staged uris would be sent as ftp:// to the remote backend but locally stored in a file:// uri... does the backend need to participate in the formatting of the uris that will be sent to it ? That is one possibility. Don't forget that the local file backend also has to rewrite the URI (from staging dir to final location). Perhaps the backend needs to claim that it supports a list of protocols for staging data (such as 'file','http','ftp' etc) ? The staging dir would be, by definition, local. I don't think we should support anything else. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Pützstr. 5 Phone: +49-228-2493652 53129 Bonn Germany ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
On Thu, 2011-07-07 at 20:39 -0400, Tristan Van Berkom wrote: I now have a much simpler patch up on the openismus-work branch[0]. (it's also in patch form on the bug[1]). That looks a lot saner than the previous solution. Removing all the attempts to keep clients perfectly informed about file removal has paid off. I haven't done a detailed code review. I'd prefer to have the EDS experts do that. But perhaps one change first: this code seems useful for a variety of local backends. I think the bulk of it should be in the shared libedata-book library. Also there is a strange use case worth pointing out: You are not allowed to use an addressbook generated uri as the uri for another field of the same contact or another contact. So you are allowed to set multiple contacts photo fields to point to http://hostyouravatar.com/buster.png;, but you are not allowed to do: /* Get that contact named Elvis Presley */ PhotoContact *photo = e_contact_get (contact_a, E_CONTACT_PHOTO); /* Use Elvis's face on this new contact I'm creating */ PhotoContact *new_photo = create_photo (photo-data.uri); e_book_commit_contact (new_photo); Not sure if that's an acceptable rule or not, if not then we either need to add some complex code to implement internal refcounting on the uris in the backend... or perhaps we could trap the incoming shared uris and create copies on disk instead... I would trap the incoming URI and create a hardlink under a different name. That'll share the data without requiring us to implement refcounting in the backend. In any case, I think we could try to close this first and then look at the staging directory feature separately, seeing that this code will very easily scale from: a.) If the incoming photo is a binary blob to... b.) If the incoming photo is a binary blob or a uri inside the staging directory... I agree. We can always do another iteration if the D-Bus overhead for storing photos becomes important. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] calendar events with category list - Evolution 2.32
On Fri, 2011-07-08 at 14:25 +0100, Valluri, Amarnath wrote: When see this event in Evolution-2.32 UI(Import Assistant), only the last(Business) category is shown. This does not only affect importing or syncing. The easiest way to reproduce the problem is to create an event in the Evolution UI with two categories selected. Only one category is visible in the UI after saving the event. I have not checked whether searching works; it might also be affected. I could see the same issue reported by Patrick on Evolution-2.10 but the issue is still present in 2.32. Not quite: the old issue was related to broken comma handling in libical, which caused two categories to be stored as CATEGORIES:abc\,xyz although the RFC specifies a simple comma as separator. Later libical was changed, which now seems to cause the current problem. Has anyone noticed this before? -- Patrick Ohly patrick.o...@gmx.de ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
On Wed, 2011-07-06 at 16:16 -0400, Tristan Van Berkom wrote: [staging directory for out-of-band photo data transmission] This alternative proposal is strictly regarding the photo data for which the server must take ownership of I assume, correct ? Yes. I might not have been clear enough in my proposal but I only intend for new or modified photos to be sent to the addressbook. Understood. I personally don't mind the D-Bus overhead in these cases because I consider them rare. But there are people who run massive write benchmarks against EDS anyway and do flag low performance in them as a problem. So if we can find a solution that also optimizes the write performance, then it would be better. The staging directory you propose if I understand it correctly would also be used under only the same circumstances, I suppose the questions are: o What is faster: writing a file to a staging directory and then moving it to a permanent location or sending the blob once over D-Bus and saving it to the permanent location. If the photo data needs to be stored as file and moving the file into its permanent location can be done with a rename, then the staging directory approach is faster. I expect writing the file to be equally fast, regardless of who does it. Sending inline data adds D-Bus overhead (considerable for large chunks of data!) and encoding/decoding overhead. o What is more reliable ? (it seems that there are less points of failure when sending the blob but I could be wrong). Agreed. I tried to mitigate that with the rules around cleaning up the staging directory. Perhaps the staging directory is a little faster when batching lots of photo modifications during a 'sync' operation ? (the client gets to write to disk while waiting for the server to be ready for the next batch of contact additions perhaps ?) At any rate, if it's judged that the performance gain of using a staging directory is worth the added complexity then let's do it. I'd like to hear some other opinions about this. Ross? I think the more important issue at hand is that to offer a reliable api for EBookView then the backend has to track the views which have received notification of the contact modifications. In other words when I have an EBookView and I have been notified that a contact exists with a photo at a given uri path, then until I receive notification that that uri is invalid, removed or replaced with a new one... I should be able to access that file. I don't see this as a problem. When a process fails to load a photo because the contact was already removed on the server together with that photo, then shortly after the attempt to read the photo the process will get the notification that the contact is gone and thus the process no longer needs the photo. I also think that this is a very rare situation. Definitely doesn't justify adding complex code to the D-Bus interface between libebook and EDS. Another hard limitation is regarding storing uris for which you don't want the addressbook to assume ownership of. The clean way as far as I can see is whoever is responsible for adding an 'alien uri' to an addressbook is responsible for removing that entry from the addressbook at the time that the uri might be deleted. Agreed. But I don't think there is a clean and efficient way of solving this. It'll be much simpler to accept that there will be URIs that point to deleted files. The intention is to not use URIs pointing to arbitrary local files. Therefore we don't need to provide a solution that assists apps who want to do that. Well... perhaps we should just swallow the ugly race and do nothing about it and say that: a uri might be invalid from time to time directly before your view receives notification of the removal ? Would that be acceptable ? Yes. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
On Thu, 2011-07-07 at 15:09 +0530, Chenthill wrote: I like the staging directory approach. Would it be possible for implementing the logic to convert the inline data -file inside e_book_client_add_contact so that the clients need to worry about changing the code ? need *not* worry, right? Yes, I can imagine that this would work. Should we allow to enable or disable this client side? In other words, should we force the separate storing of photo data in all cases or is there a legitimate situation where a client might want to force the data to be stored inline? I can't think of one myself. Note that once we introduce this mechanism (whether it is mandatory or not), all clients must be prepared to deal with PHOTO URIs. But this is not new, because there might already be contacts in current EDS with URIs. The only change would be that clients get an URI for their *own* contacts even if those had inline data. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] improve PHOTO support in libebook/EDS
Hello! It was pointed out before that support for PHOTO data in EDS is sub-optimal because the data has to be encoded as B64 data in the vCard and then gets transmitted like that via D-BUs and stored in Berkley DB. A high-level description of the problem is here: http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements#Contacts:_Store_PHOTO_Data_as_Plain_Files Photos should be transferred over D-Bus via a filepath to a local file rather than transferring the actual photo data over D-Bus. The VCard format already allows this option (See the PHOTO property). We must be careful to keep these local files in sync and to remove them when contacts are removed, and to restrict access to the files from other processes. There should be utility code available to libebook users to convert between the different representations. Goals: 1. Apps should be able to create photo files without ever passing the data to libebook. 2. External PHOTO file and corresponding contact must be kept in sync: 1. If a contact is deleted, the photo also needs to be removed. 2. If a photo file is created and then storing the contact fails, who removes the file? 3. Access to photo data must be limited to processes which have the right permissions. --- There also was a proposal for how to solve this, but I am no longer entirely happy with it. Openismus is working on this at the moment, see https://bugzilla.gnome.org/show_bug.cgi?id=652178 Before diving further into prototyping or implementing a solution, I would like to come to an agreement about the client visible behavior and a rough outline how to implement it. First let me clarify that we need to distinguish two different use cases: 1. The photo app owns and manages a set of photos. A link is added to a contact. If the contact is deleted, the photo must remain because it is part of a slide show. If the photo is moved or renamed, the link remains but is obviously no longer useful (dangling link as in a symbolic link in a file system). 2. Photo data is attached to a contact. EDS becomes the owner for the data and must ensure that it is stored and deleted together with the contact. Apps get access to the photo via its URI, exactly as in the first case. The extension that we are discussing addresses the second point. It must not break the first one. Tristan's plan seems to be to pass the PHOTO data inline in the vCard to the file backend and to strip it out there. Note that this is not optimal in terms of performance: if the data is already available separately (as it is in syncing, for example), then it has to be inlined and transferred via D-Bus (slow). This is acceptable because contacts are read a lot more often than written. But that doesn't stop people from running write benchmarks ;-) I'd only go down that route if it really makes the implementation a lot simpler. From the description in 652178 and private email it doesn't sound like it necessarily does. How about a different approach: * Each EBookClient can request a staging directory. If the backend supports this mechanism, it is created for this client by EDS. If not, the client has to inline PHOTO data as before. * The content of the staging directory is ephemeral. When a client crashes or disconnects, EDS removes the directory and everything inside it. When EDS crashes, it cleans up all staging directories when it restarts. * If a client wants EDS to take ownership of the photo, it creates a file in the staging directory with an arbitrary name and sets the PHOTO URI such that it points to it with an absolute path. * The client submits the contact. At that point it stops being responsible for the file. * The EDS backend checks for such special PHOTO URIs. If it finds one, it copies or moves the file to its permanent location and updates the URI before storing the contact and notifying clients. Note that backends are free to do that however they want. For example, a CardDAV backend might upload the file data to a resource on the HTTP server and set the PHOTO URI to a http:// URL. The file backend chooses a staging directory in the same file system as the permanent photo directory and thus can simply move the file instead of having to copy it. libebook might offer some additional utility code to simplify the handling of such a staging directory and PHOTO URIs. API to be decided, also for the request a staging directory part. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your
Re: [Evolution-hackers] Categories
On Do, 2011-06-23 at 07:14 -0400, Adam Tauno Williams wrote: When saving a task or event over a CalDAV collection Evolution sends a CATEGORIES attribute like: CLASS:PUBLIC CATEGORIES:Favorites\,Gifts\,Goals/Objectives PERCENT-COMPLETE:0 Looking at RFC2445 I'm pretty sure this is wrong. Upstream libical used to have a bug around that. It should be fixed in 0.44. I don't know whether Evolution itself still has it wrong somewhere. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Di, 2011-06-14 at 07:38 -0400, Matthew Barnes wrote: On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote: My two cents as a user of these APIs: having to deal with a major API change once is acceptable. Whether it is in 3.2 or 3.4 I don't really care. But having to rewrite code both for 3.2 *and* 3.4 goes a bit too far. So if the account handling doesn't land in 3.2, then please let's keep the current (EDS 3.0) APIs officially supported in 3.2. There are no major (nor minor, that I'm aware of) public API breaks in 3.1 as of yet, just new alternative APIs for EBook and ECal. EBook and ECal are deprecated but still work the same, I'm relieved to hear that. Milan had me worried for a while with the talk about deprecating these calls, but I only misunderstood the implications. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Do, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote: On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: I hope not, I'm currently working on evo bits to be buildable with E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is done, but I'm postponing it till I have evo and the standard rest done as well). Having one API deprecated and second unstable doesn't sound good to me, same as there doesn't seem to be many things to change anyway. We can always increase .so name version, that's just for it, isn't it? Anything in the EClient API dealing with ESourceList, URI strings, or default sources will be removed when the account-mgmt branch is merged, and there's a fair chance now that may not happen until 3.3. So the API is unstable whether we claim it to be or not. My two cents as a user of these APIs: having to deal with a major API change once is acceptable. Whether it is in 3.2 or 3.4 I don't really care. But having to rewrite code both for 3.2 *and* 3.4 goes a bit too far. So if the account handling doesn't land in 3.2, then please let's keep the current (EDS 3.0) APIs officially supported in 3.2. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [EDS PATCHES] ecal item semantic (was: [Fwd: Re: e_cal_remove_object_with_mod() + empty rid: semantic?])
On Mo, 2011-06-06 at 08:00 +0530, chen wrote: Can you please attach these patches on to bugzilla ? I will put the comments there. I can do it myself, but there is no option to specify the author, so it would be better if you can do it.. Sure. See https://bugzilla.gnome.org/show_bug.cgi?id=651970 -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [EDS PATCHES] ecal item semantic (was: [Fwd: Re: e_cal_remove_object_with_mod() + empty rid: semantic?])
Hello Chenthill! You are the calendar maintainer, right? Do you have some time to review these patches? On this occasion let me add some further explanation of the motivation for this patch series. Traditionally, libecal has implemented parts of the semantic typically associated with a UI: for example, it implements ensure that a recurring event does not occur at this point in time, no matter what it takes to achieve that. I consider this a high-level API. The low-level API would be remove/add/modify this VEVENT. The libecal API *looks* like it supports that and according to our previous discussion is meant to (see the comments about e_cal_remove_object_with_mod()), but the actual implementation differs. This is a problem for sync operations, where that semantic is implemented elsewhere and the calendar storage has to mirror the operations done there (CalDAV/SyncML server in SyncEvolution; KCal in the MeeGo architecture). Therefore this patch series adds the missing operations. This is done so that the file backend can replace other local storages that EDS is being compared against. I understand that the vision of EDS goes beyond just being a local storage, but that's irrelevant in the context of such comparisons (unfortunately). -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ---BeginMessage--- On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote: I'll do it as uid[\nrid] so that entries without an rid continue to look exactly like the current ones. Looks good. I ran my KCal-EDS test program which adds, modifies and removes events, including parent and child (= detached recurrence) in various orders. I am now seeing all ECalView signals that I expect and need. I also ran Evolution in parallel to the test and saw it react to all signals, but not quite as I would have liked. Evolution seems to interpret uid + empty rid as all recurrences removed, which IMHO is wrong. It should mean parent removed, because otherwise there is no way of expressing that change. For child removed, parent not updated (= no EXDATE added) I would expect Evolution to show the original, unmodified recurrence again. Instead it only removes the recurrence (as if EXDATE had been added). I consider this an Evolution bug which can and should be fixed separately. Please understand that it is currently lower priority for me, my main goal has to be to get EDS working as intended in EKCal-EDS, without Evolution. Please have a look at the attached patch series. They were tested with the gnome-2-32 branch. Except for the very last one, all apply to master. Does this look okay? May I submit to master (after fixing the last patch), gnome-3-0 and gnome-2-32? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ From 2e128c63a4a9dd64a3a327262498deb869a119f7 Mon Sep 17 00:00:00 2001 From: Patrick Ohly patrick.o...@intel.com Date: Wed, 11 May 2011 16:59:51 +0200 Subject: [PATCH 1/8] calendar file backend: support removing parent event with CALOBJ_MOD_THIS It was possible to create a meeting series with just a detached event (RECURRENCE-ID set) by importing a meeting invitation for that single recurrence. It was not possible to arrive at that same state after adding the parent event (the one with the RRULE) because e_cal_remove_object_with_mod() removed all instances for CALOBJ_MOD_THIS and empty rid. This contradicts the intended semantic of e_cal_remove_object_with_mod(): By using a combination of the @uid, @rid and @mod arguments, you can remove specific instances. If what you want is to remove all instances, use e_cal_remove_object instead. This patch implements the desired semantic: - e_cal_backend_file_remove_object(CALOBJ_MOD_THIS) now always calls remove_instance(). - remove_instance() was extended to also work for the parent event. - That call removes the complete object if nothing is left after removing the instance. This case must be handled by the caller. The return value is the original object (if it still exists) and NULL if not. - Because the uid pointer into the object may become invalid as part of the removal, a more permanent pointer has to be provided by the caller. --- calendar/backends/file/e-cal-backend-file.c | 134 ++- 1 files changed, 88 insertions(+), 46 deletions(-) diff --git a/calendar/backends/file/e-cal-backend-file.c b/calendar/backends/file/e-cal-backend-file.c index 33bab50..7a8c450 100644 --- a/calendar/backends/file/e-cal-backend-file.c +++ b/calendar/backends/file/e-cal-backend-file.c @@ -2629,47 +2629,94 @@ e_cal_backend_file_modify_object (ECalBackendSync *backend, EDataCal *cal, const g_static_rec_mutex_unlock (priv-idle_save_rmutex); } -static void -remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *rid) +/** + * Remove one and only one instance. The object may be empty + * afterwards, in which case it will be removed completely. + * + * @uidpointer to UID which
Re: [Evolution-hackers] Issues with new EBook dbus implementation
On Fr, 2011-05-27 at 11:59 -0400, Matthew Barnes wrote: On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote: Maybe it can pump them, but it doesn't deliver them, as far as my tests showed, because they are usually delivered on idle, which never happen with blocked main loop. That's the reason why I added there this loop. Only notice that this loop is running for sync calls, and only if it's done from the main thread. The async calls and sync calls from a dedicated thread doesn't do any such thing. You may not use sync calls in your application, preferably. (Same as evolution shouldn't, which is subject to change, to use the EBOok/CalClient APIs directly.) Can't we just consider it a programming error for a D-Bus method to be called synchronously from the main thread? I don't see any reason to support this case since it would be by definition a bug. I beg to differ. A command line tool like SyncEvolution is perfectly usable with blocking the main thread in the synchronous API calls. Or rather, it works as good as the synchronous API implementation. One problem are timeouts. The other is that the calls don't detect when the server dies because the corresponding D-Bus signal is not delivered (seen in older EDS releases, not sure how relevant it is on master). As Alexander said, the synchronous API serves a useful purpose. SyncEvolution is one, simple tests another. +1 for keeping it and fixing it so that it really works. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 32 bit IDs in contact file backend
On Mi, 2011-05-18 at 07:34 +0200, Milan Crha wrote: On Tue, 2011-05-17 at 17:19 +0200, Patrick Ohly wrote: On Di, 2011-05-17 at 16:25 +0200, Milan Crha wrote: On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote: I'm not sure if I got it right, but such workarounds are just wrong from my point of view. You cannot force servers to use certain types of IDs because of constraints given by application which tries to connect to it. We can't force a server. But we can adapt the file backend. That's what I didn't get fully from your conversation with David. What is the gain to change file backend when there are all other backends which will be unusable with QtContacts because they cannot do 32-bit int UIDs? Once we have the mapping, it is an optimization. Without the mapping, it is the only way to get the system working. Was it just to have it done natively in the most common backend and all the rest will use mappings in the QtContacts-EDS interface? Yes. It might be harder to spot bugs in the first or the second part of the code (with or without intermediate mappings), isn't it? This argument can be turned around: because we don't need the mapping with the 32 bit patch applied, we can focus on the rest of the code, test in a working system, and later extend it. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
I'll do it as uid[\nrid] so that entries without an rid continue to
look exactly like the current ones.
Looks good. I ran my KCal-EDS test program which adds, modifies and
removes events, including parent and child (= detached recurrence) in
various orders.
I am now seeing all ECalView signals that I expect and need.
I also ran Evolution in parallel to the test and saw it react to all
signals, but not quite as I would have liked.
Evolution seems to interpret uid + empty rid as all recurrences
removed, which IMHO is wrong. It should mean parent removed, because
otherwise there is no way of expressing that change.
For child removed, parent not updated (= no EXDATE added) I would
expect Evolution to show the original, unmodified recurrence again.
Instead it only removes the recurrence (as if EXDATE had been added).
I consider this an Evolution bug which can and should be fixed
separately. Please understand that it is currently lower priority for
me, my main goal has to be to get EDS working as intended in EKCal-EDS,
without Evolution.
Please have a look at the attached patch series. They were tested with
the gnome-2-32 branch. Except for the very last one, all apply to
master. Does this look okay? May I submit to master (after fixing
the last patch), gnome-3-0 and gnome-2-32?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
From 2e128c63a4a9dd64a3a327262498deb869a119f7 Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Wed, 11 May 2011 16:59:51 +0200
Subject: [PATCH 1/8] calendar file backend: support removing parent event with CALOBJ_MOD_THIS
It was possible to create a meeting series with just a detached event
(RECURRENCE-ID set) by importing a meeting invitation for that single
recurrence. It was not possible to arrive at that same state after
adding the parent event (the one with the RRULE) because
e_cal_remove_object_with_mod() removed all instances for
CALOBJ_MOD_THIS and empty rid.
This contradicts the intended semantic of e_cal_remove_object_with_mod():
By using a combination of the @uid, @rid and @mod
arguments, you can remove specific instances. If what you want
is to remove all instances, use e_cal_remove_object instead.
This patch implements the desired semantic:
- e_cal_backend_file_remove_object(CALOBJ_MOD_THIS) now always
calls remove_instance().
- remove_instance() was extended to also work for the parent
event.
- That call removes the complete object if nothing is left
after removing the instance. This case must be handled by
the caller. The return value is the original object (if
it still exists) and NULL if not.
- Because the uid pointer into the object may become invalid
as part of the removal, a more permanent pointer has to
be provided by the caller.
---
calendar/backends/file/e-cal-backend-file.c | 134 ++-
1 files changed, 88 insertions(+), 46 deletions(-)
diff --git a/calendar/backends/file/e-cal-backend-file.c b/calendar/backends/file/e-cal-backend-file.c
index 33bab50..7a8c450 100644
--- a/calendar/backends/file/e-cal-backend-file.c
+++ b/calendar/backends/file/e-cal-backend-file.c
@@ -2629,47 +2629,94 @@ e_cal_backend_file_modify_object (ECalBackendSync *backend, EDataCal *cal, const
g_static_rec_mutex_unlock (priv-idle_save_rmutex);
}
-static void
-remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *rid)
+/**
+ * Remove one and only one instance. The object may be empty
+ * afterwards, in which case it will be removed completely.
+ *
+ * @uidpointer to UID which must remain valid even if the object gets
+ * removed
+ * @ridNULL, , or non-empty string when manipulating a specific recurrence;
+ * also must remain valid
+ * @return modified object or NULL if it got removed
+ */
+static ECalBackendFileObject *
+remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *uid, const gchar *rid)
{
gchar *hash_rid;
ECalComponent *comp;
struct icaltimetype current;
- if (!rid || !*rid)
- return;
+ /* only check for non-NULL below, empty string is detected here */
+ if (rid !*rid)
+ rid = NULL;
- if (g_hash_table_lookup_extended (obj_data-recurrences, rid, (gpointer *)hash_rid, (gpointer *)comp)) {
- /* remove the component from our data */
+ if (rid) {
+ /* remove recurrence */
+ if (g_hash_table_lookup_extended (obj_data-recurrences, rid,
+ (gpointer *)hash_rid, (gpointer *)comp)) {
+ /* remove the component from our data */
+ icalcomponent_remove_component (cbfile-priv-icalcomp,
+ e_cal_component_get_icalcomponent (comp));
+ cbfile-priv-comp = g_list_remove (cbfile-priv-comp, comp);
+ obj_data-recurrences_list = g_list_remove (obj_data-recurrences_list, comp);
+ g_hash_table_remove (obj_data-recurrences, rid);
+ } else {
+ /* not an error, only add EXDATE
Re: [Evolution-hackers] 32 bit IDs in contact file backend
On Do, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote: Attached the resulting patch. Note that with the patch applied, all new contacts in a Berkley DB get the simpler IDs, unconditionally. Older contacts continue to use their existing IDs. Would something like this be acceptable upstream? Any thoughts on this? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 32 bit IDs in contact file backend
On Di, 2011-05-17 at 18:49 +0530, Chenthill wrote: On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote: | Further work if you agree in principle: | * let clients query whether all contacts have the simplified ID - |could be done with the dynamic capabilities that I mentioned in |the e-client API thread; avoids reading all contact (UIDs) This sounds like a better solution than adding constraints on eds end. I prefer to think of it as an additional promise to the libebook user, not a constraint. One possibility which came to my mind [requires more thoughts] was to bring the uid generation (e_book_backend_file_create_next_uid) function into EBookBackend as a virtual function. Then you could have a external backend for qtcontacts subclassing EBookFileBackend and over-riding the create_next_uid function alone. I haven checked if other backend's would need this virtual function though. Maybe webdav might use it ? And then what? Build and maintain out-of-tree MeeGo versions of all backends? Quite frankly, patching the existing backends sounds less risky to me. Of course, including these changes upstream would be best. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 32 bit IDs in contact file backend
On Di, 2011-05-17 at 16:25 +0200, Milan Crha wrote: On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote: I'm not sure if I got it right, but such workarounds are just wrong from my point of view. You cannot force servers to use certain types of IDs because of constraints given by application which tries to connect to it. We can't force a server. But we can adapt the file backend. Your interface between QtContacts and eds may hide this QtContacts implementation detail, to be able to support any book backend, current or future. This might not be done in eds backend itself, from my point of view. might not or must not? Anyway, the direction is clear: add the mapping code to QtContacts-EDS, as soon as time allows. We are juggling resources between various tasks at the moment, so I'd say as long as we have a solution that works for the time being, I'd rather see other problems addressed first. While we do that, the 32 bit patch should remain outside upstream EDS. Once we have the mapping code, we can revisit that question by doing a direct comparison with and without it. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
On Mo, 2011-05-16 at 08:11 +0200, Milan Crha wrote: On Fri, 2011-05-13 at 15:44 +0200, Patrick Ohly wrote: In libebook, I get a Timeout was reached because the asynchronous operation doesn't complete quickly enough. Same for the attempt to delete the contacts. The gError-code is 24, which is indeed E_BOOK_ERROR_NOT_SUPPORTED. Hi, as long as it's GError, you cannot compare only GError::code, because the correct way to identify the error is using the whole pair GError::domain and GError::code. Your domain for Timeout was reached is most likely G_IO_ERROR with a code G_IO_ERROR_TIMED_OUT. Indeed, that explains it. In principle I know that, I just forgot to check in this case ;-} The new eclient stuff will not suffer of this (unless some backend will block main thread for too long). The EClient may not time out, but taking several minutes of 100% CPU time just to safe a handful of contacts just can't be right. I've no idea about libdb, thus only referring to the error. I have one notice though, the EBook calls are served and processed mostly as soon as they come, and they can come in parallel too. The backend itself may make sure that it'll not make any trouble, like by some busy lock. libdb is supposed to be thread-safe, so in theory shouldn't need such a lock. Either libdb is broken or EDS is not using it correctly (wrong environment, for example). Looking at the DB API [1] I see this flag for opening the environment: DB_INIT_LOCK Initialize the locking subsystem. This subsystem should be used when multiple processes or threads are going to be reading and writing a Berkeley DB database, so that they do not interfere with each other. If all threads are accessing the database(s) read-only, locking is unnecessary. When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well. See db_deadlock and DB_ENV-lock_detect() for more information. EDS does not pass this flag, although it has concurrent reads *and* writes. The behavior in that case is undefined as far as I can tell. The downside of using DB_INIT_LOCK is that deadlocks are possible and need to be checked by regularly calling lock_detect(). It might be easier to set DB_INIT_CDB, which enforces multiple reads/single writer access without deadlocks. I'll give that a try. [1] http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/envopen.html -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
[Milan, can you please keep other people on CC?
I know that you personally prefer to not be CCed on mailing list emails
and I try to remember that in my own replies, but others are not on the
list and may depend on being CCed. For example, I don't know whether
Chris is subscribed.]
On Mo, 2011-05-16 at 11:12 +0200, Patrick Ohly wrote:
It might be easier to set DB_INIT_CDB, which enforces multiple
reads/single writer access without deadlocks. I'll give that a try.
And it works beautifully. One word added to the source code and the
stress test passes reliably and quickly :-)
Patch attached. Okay to submit into master (not tested there, though)
and gnome-2-32 branches (which is where I have tested it)?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
From 2b4cff9230a049d5ad7fe86873aba9a7bba35af1 Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Mon, 16 May 2011 11:21:04 +0200
Subject: [PATCH] addressbook file backend: libdb must be initialized for concurrent read/write
Very bad performance (100% CPU load, several minutes run time) were
seen for multiple concurrent writes. gdb shows that libdb is
apparently busy polling while writing.
The libdb API docs for DB_ENV-open() imply that either DB_INIT_CDB or
DB_INIT_LOCK must be used in apps which are not read-only, like
EDS. This patch adds DB_INIT_CDB because it is simple and fixes the
performance problem.
In some rare cases, DB_INIT_LOCK might provide better performance by
allowing concurrent writes of independent data, but that seems too
complicated for not enough gain right now (must check for deadlocks).
---
addressbook/backends/file/e-book-backend-file.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/addressbook/backends/file/e-book-backend-file.c b/addressbook/backends/file/e-book-backend-file.c
index d21c527..372ade5 100644
--- a/addressbook/backends/file/e-book-backend-file.c
+++ b/addressbook/backends/file/e-book-backend-file.c
@@ -1146,7 +1146,18 @@ e_book_backend_file_load_source (EBookBackend *backend,
(gpointer (*)(gpointer , gsize))g_try_realloc,
g_free);
- db_error = (*env-open) (env, NULL, DB_CREATE | DB_INIT_MPOOL | DB_PRIVATE | DB_THREAD, 0);
+ /*
+ * We need either DB_INIT_CDB or DB_INIT_LOCK, because we will have
+ * multiple threads reading and writing concurrently without
+ * any locking above libdb.
+ *
+ * DB_INIT_CDB enforces multiple reader/single writer by locking inside
+ * the database. It is used instead of DB_INIT_LOCK because DB_INIT_LOCK
+ * may deadlock, which would have to be called in a separate thread.
+ * Considered too complicated for not enough gain (= concurrent writes)
+ * at this point.
+ */
+ db_error = (*env-open) (env, NULL, DB_INIT_CDB | DB_CREATE | DB_INIT_MPOOL | DB_PRIVATE | DB_THREAD, 0);
if (db_error != 0) {
env-close(env, 0);
g_warning (db_env_open failed with %s, db_strerror (db_error));
--
1.7.2.5
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
On Mo, 2011-05-16 at 13:05 +0200, Milan Crha wrote: On Mon, 2011-05-16 at 11:35 +0200, Patrick Ohly wrote: And it works beautifully. One word added to the source code and the stress test passes reliably and quickly :-) Patch attached. Okay to submit into master (not tested there, though) and gnome-2-32 branches (which is where I have tested it)? Yes please, master, gnome-3-0 and if you want then gnome-2-32 too. Thanks. Okay, done. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Do, 2011-05-12 at 13:17 +0200, Milan Crha wrote: On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote: I found this in e-data-cal-view.c notify_remove(): 280 /* TODO: store ECalComponentId instead of just uid*/ 281 uid = g_strdup (id-uid); 282 g_array_append_val (priv-removes, uid); In other words, removes always come without rid, even if the actual event that was removed was not the parent but a detached recurrence. ... It'll lead to a change of the D-Bus API. For master that shouldn't be a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I guess we have to bite the bullet and maintain a MeeGo version with a different API than regular 2.32.x. Hi, I noticed it too, recently (at the beginning of this week, actually). I suggest to not change the D-Bus API, rather encode the string pair into the string, like uid\nrid. I was planning to do so in the master branch, but didn't do that yet. That's still a D-Bus API change: a libecal which receives a UID entry in that format won't know what to do with it. But it'll be easier to implement that way, so I'll give it a try first. I'll do it as uid[\nrid] so that entries without an rid continue to look exactly like the current ones. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
Hello Ross!
Can you perhaps comment? You wrote the TODO items below...
On Di, 2011-05-03 at 18:04 +0200, Patrick Ohly wrote:
I also wonder about the objects-removed signal in ECalView. If there
are two events, one with RRULE and one with RECURRENCE-RULE, and both
get removed, should there be two entries in objects-removed?
I found this in e-data-cal-view.c notify_remove():
280 /* TODO: store ECalComponentId instead of just uid*/
281 uid = g_strdup (id-uid);
282 g_array_append_val (priv-removes, uid);
In other words, removes always come without rid, even if the actual
event that was removed was not the parent but a detached recurrence.
There's another, similar TODO in send_pending_removes():
192 /* TODO: send ECalComponentIds as a list of pairs */
193 e_gdbus_cal_view_emit_objects_removed (view-priv-gdbus_object,
(const gchar * const *) priv-removes-data);
And sure enough, the actual D-Bus API uses an array of strings instead
of an array of string pairs.
I can fix these TODOs. Any objections or concerns?
It'll lead to a change of the D-Bus API. For master that shouldn't be
a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
guess we have to bite the bullet and maintain a MeeGo version with a
different API than regular 2.32.x.
One more question about e_cal_backend_notify_object_removed(): it takes
iCalendar 2.0 object strings as parameter in addition to the id. If both
are set, it acts like object_updated. If the new object is NULL, it
checks whether the old_object matches the view. Is that really
necessary? There is a second check whether the ID is in the view in
e_data_cal_view_notify_objects_removed():
701 for (l = ids; l; l = l-next) {
702 ECalComponentId *id = l-data;
703 if (g_hash_table_lookup (priv-ids, id))
704 notify_remove (view, id);
705 }
At least that is my understanding. So is it safe to pass only the ID and
old_object = object = NULL?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] NO_THISANDFUTURE/THISANDPRIOR and file backend
Hello! Why does the file backend claim that it doesn't support CAL_STATIC_CAPABILITY_NO_THISANDFUTURE and CAL_STATIC_CAPABILITY_NO_THISANDPRIOR? There is code for these in remove_object_instance_cb(), e_cal_backend_file_modify_object() and e_cal_backend_file_remove_object(). Is all of that dead code that was never used and tested? I don't need this feature, I just wonder. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Di, 2011-05-10 at 10:23 +0200, Milan Crha wrote: On Wed, 2011-05-04 at 17:31 +0200, Patrick Ohly wrote: On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote: On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote: I would expect that with CALOBJ_MOD_THIS it may remove only exact component, for uid + NULL-rid the master object (which implies also all generated instances) and keep all detached instances, Okay, then we agree on the desired semantic. I ran into another oddity: suppose there is a recurring event without exceptions and a detached recurrence gets added. The libecal API does not support undoing that operation. ... Hi, it sounds like you might find useful an addition of a reverse function for gboolean e_cal_client_get_object_sync ( ECalClient *client, const gchar *uid, const gchar *rid, icalcomponent **icalcomp, GCancellable *cancellable, GError **error); which can return either one component, or a VCALENDAR component. I'm thinking of something like: e_cal_client_replace_object (..., const gchar *uid, /* const */ icalcomponent *icalcomp, ...); Note it doesn't take the 'rid' parameter as the get_object function. Yes, there might be cases where that is better than the current API. But I see it as complementary to enhancing the existing, single-event focused APIs. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
On Di, 2011-05-10 at 11:40 +0100, Dumez, Christophe wrote: I have tested the patch but it does not seem to help. I don't know what the reason is yet. If you have never run Evolution, there will be no gconf entries for addressbook. The second part of the fix was to have libecal create this entry when creating a new system address book. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
Hello! It seems that a similar problem exists in libebook if no address books were created already by Evolution. Chris is seeing such an issue with 2.32.3 in MeeGo. We probably need to add the create GConf entry for local:system part to libebook in the gnome-2-32 branch. Is that something that is still of interest for Trunk, given that EClient API will obsolete it for 3.2? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf
On Di, 2011-05-10 at 09:34 +0100, David Woodhouse wrote: On Tue, 2011-05-10 at 10:19 +0200, Patrick Ohly wrote: It seems that a similar problem exists in libebook if no address books were created already by Evolution. Chris is seeing such an issue with 2.32.3 in MeeGo. Oh, tits. I hate the fact that all this code is so *gratuitously* separate. Yeah, me too. 3.2 will be better, but will still have separate libebook/libecal libraries. We probably need to add the create GConf entry for local:system part to libebook in the gnome-2-32 branch. Is that something that is still of interest for Trunk, given that EClient API will obsolete it for 3.2? It's still relevant for now, so let's do it. We *could* make a case for not bothering, and just fixing it in 3.0 and 2.32 instead. But our policy is to backport only fixes from master, and I prefer not to set a counter-precedent unless I absolutely have to. It doesn't *hurt* to fix it in master first. Do you have a patch? Sorry, no. And no time either :-/ -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mo, 2011-05-09 at 17:00 +0200, Milan Crha wrote: On Wed, 2011-05-04 at 14:37 +0200, Milan Crha wrote: So here left basically three things, a) merging some API in utils, b) getting well-known properties, c) setting well-known properties Hi, I just did a commit into the eclient branch with a fix for b) and c). There is a little change, I named those functions: e_client_get_backend_property_sync e_client_set_backend_property_sync with their async versions too. Well-known properties are: * for a book: BOOK_BACKEND_PROPERTY_LOADED BOOK_BACKEND_PROPERTY_ONLINE BOOK_BACKEND_PROPERTY_READONLY BOOK_BACKEND_PROPERTY_CACHE_DIR BOOK_BACKEND_PROPERTY_CAPABILITIES BOOK_BACKEND_PROPERTY_REQUIRED_FIELDS BOOK_BACKEND_PROPERTY_SUPPORTED_FIELDS BOOK_BACKEND_PROPERTY_SUPPORTED_AUTH_METHODS * for a calendar: CAL_BACKEND_PROPERTY_LOADED CAL_BACKEND_PROPERTY_ONLINE CAL_BACKEND_PROPERTY_READONLY CAL_BACKEND_PROPERTY_CACHE_DIR CAL_BACKEND_PROPERTY_CAPABILITIES CAL_BACKEND_PROPERTY_CAL_EMAIL_ADDRESS CAL_BACKEND_PROPERTY_ALARM_EMAIL_ADDRESS CAL_BACKEND_PROPERTY_DEFAULT_OBJECT Why duplicate the LOADED/ONLINE/READONLY/CACHE_DIR/CAPABILITIES properties? They could be defined as common E_CLIENT_BACKEND_ properties. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote: I would expect that with CALOBJ_MOD_THIS it may remove only exact component, for uid + NULL-rid the master object (which implies also all generated instances) and keep all detached instances, Okay, then we agree on the desired semantic. though this operation doesn't seem to have much sense to me. It's certainly not a common operation, but the API should allow it nevertheless, because otherwise correct synchronization between a database where such an operation took place (for whatever reason) and EDS is hard. The problem is that each backend has its own implementation of such operation (also note that groupwise backend has no master object (it tells it in capabilities)) and for example file backend behaves with rid=NULL mod=CALOBJ_MOD_THIS the same like with mod=CALOBJ_MOD_ALL, thus it drops also detached instances. If a backend doesn't support the semantic, then there's not much that can be done. But the file backend should be able to to handle it, therefore I consider it a bug that it removes all instances in this case. I'll look into fixing this. I also wonder about the objects-removed signal in ECalView. If there are two events, one with RRULE and one with RECURRENCE-RULE, and both get removed, should there be two entries in objects-removed? I've no idea on this. I'm sorry. First things first ;-) Let me fix the removal, then look into this problem here. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mi, 2011-05-04 at 14:37 +0200, Milan Crha wrote: Hi, I'm getting slightly lost what is left and what is under discussion, thus please let me summarize things here: On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: First of all, +1 for rethinking the API. I'd like to suggest that besides modernizing the API we also take this opportunity to move more of EBook/ECal into a common core. It seems strange to me to have EClientSourceType defined in e-client.h and its main usage in other file (remember of compiler dependency issue), thus I suggest to keep e-client/e-book-client/e-cal-client as they are and rename e-client-authentication.h/.c (which resides in libedataserverui) to e-client-utils.h/.c and do common interfaces here. This is including also e_client_open_new() being defined here. This is for client-side code merging. I still think that list and open databases are common operations and that having different libraries and code for contacts and calendar is a historic artifact. But let's not get hung up on that and move on without changing it. Talking of capabilities, I found their usefulness a bit limited because they a) cannot change during the life time of a client and b) they only report exists/doesn't exit. Here was suggested a common e_client_get_property_sync (EClient *client, const gchar *in_name, gchar **out_value, ...); function (with its async equivalent) (the e_client_get_backend_property_sync is better descriptive, less confusing with GObject properties, I guess, though it's quite long name). I'm fine with that, I can add it. Thanks. Setting values should also be allowed. That gives us a way how a client can configure the storage to behave in certain ways. This can be per-database (tweak the actual on-disk storage) or per EClient (modify behavior as part of current session). This breaks abstraction, from my point of view. The client may not know/expect anything about backends, That's not quite true in all cases. On an embedded system, a client might know exactly that it is going to be installed together with a specific backend and may want to influence that backend without having to maintain a non-upstream API for it. so any property setting from client side is not needed. Another situation would be a writable property that is supported by one or more backends. Writing in a backend which doesn't support should trigger an error, but in others it may make sense. For example, setting the color of a calendar is possible in CalDAV. A read/write property would make sense to expose that to clients. You can ask for change tag, or last modified tag, but you should not be able to change it from client side in other than _add/_modify/_remove way. change and last modified would be read-only. But other properties may be writable. Even if there are none predefined now, adding the API now is necessary to make it future-proof. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote: On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote: I would expect that with CALOBJ_MOD_THIS it may remove only exact component, for uid + NULL-rid the master object (which implies also all generated instances) and keep all detached instances, Okay, then we agree on the desired semantic. I ran into another oddity: suppose there is a recurring event without exceptions and a detached recurrence gets added. The libecal API does not support undoing that operation. e_cal_remove_object_with_mod(rid=datetime, CALOBJ_MOD_THIS) will remove the recurrence but it will *also* add an EXDATE for that recurrence. So the calendar is not in the same state as it was before adding the detached recurrence. This behavior may make sense for a UI (remove this recurrence implies adding the EXDATE), but not for syncing. May I add a CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY mode? If a backend doesn't support the semantic, then there's not much that can be done. But the file backend should be able to to handle it, therefore I consider it a bug that it removes all instances in this case. I'll look into fixing this. I have a patch ready. Will continue to test and send when the rest also passes my tests. I also wonder about the objects-removed signal in ECalView. If there are two events, one with RRULE and one with RECURRENCE-RULE, and both get removed, should there be two entries in objects-removed? I've no idea on this. I'm sorry. First things first ;-) Let me fix the removal, then look into this problem here. ECalView is indeed odd. My initial understanding is that the file backend will never send information about removed detached recurrences, so rid is always empty. What I get instead when removing a detached recurrence is a master modified with EXDATE set. I suspect that the Evolution UI uses that to remove the corresponding detached recurrence. Does anyone know whether that is the case? If I introduce the CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY, then EXDATE won't be set and a real object-removed with rid set will be needed. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
Hello! I'm running into an old nemesis of mine: how do I remove the parent event (the one with RRULE) without also removing child events (= detached recurrences, exceptions)? This is not something that is needed by the Evolution UI, but IMHO it is a valid operation. Definitely can happen during syncing or when using a different front end. It is possible to create a calendar which only has the child event in Evolution by importing a meeting invitation for just one instance of a recurring event. I consider such a calendar valid, but there is no clean way to get to that state after the parent has been added, as far as I know. e_cal_remove_object_with_mod() looks promising, but I can't get it to work: /** * e_cal_remove_object_with_mod: * @ecal: A calendar client. * @uid: UID og the object to remove. * @rid: Recurrence ID of the specific recurrence to remove. * @mod: Type of removal. * @error: Placeholder for error information. * * This function allows the removal of instances of a recurrent * appointment. By using a combination of the @uid, @rid and @mod * arguments, you can remove specific instances. If what you want * is to remove all instances, use e_cal_remove_object instead. * * If not all instances are removed, the client will get a obj_modified * signal, while it will get a obj_removed signal when all instances * are removed. * * Returns: TRUE if the operation was successful, FALSE otherwise. */ gboolean e_cal_remove_object_with_mod (ECal *ecal, const gchar *uid, const gchar *rid, CalObjModType mod, GError **error) The documentation does not explain which combination of the parameters does what. Previously, passing a NULL or empty rid (don't remember exactly, but I probably tried both at that time) confused the Exchange connector backend. Therefore it wasn't possible to remove just the parent event. In SyncEvolution I added weird hacks for this, like first retrieving all children, removing the whole series with e_cal_remove_object(), then re-adding the children. I was hoping to avoid this with more recent EDS, the local file backend and simply calling e_cal_remove_object_with_mod() regardless whether it has an rid or not. But it turns out that e_cal_remove_object_with_mod(rid=) simply calls the removeObject D-Bus method with an empty string for the rid, just like e_cal_remove_object() does, and thus all events sharing the same UID get deleted. rid=NULL doesn't make any difference. What is the intended semantic of e_cal_remove_object_with_mod()? If rid empty or NULL, then remove only parent? I also wonder about the objects-removed signal in ECalView. If there are two events, one with RRULE and one with RECURRENCE-RULE, and both get removed, should there be two entries in objects-removed? I might be misreading my debug logging, but that doesn't seem to happen. Before I dig deeper, I'd like to get some feedback on the expected semantic. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Mo, 2011-04-18 at 15:57 +0200, Milan Crha wrote: I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I believe, makes things more coherent. First of all, +1 for rethinking the API. I'd like to suggest that besides modernizing the API we also take this opportunity to move more of EBook/ECal into a common core. Opening and listing databases don't have to be separate. Turn ECalClientSourceType into EClientSourceType and all of the _new, _new_from_uri, _new_system, _new_default, _get_sources functions can be moved into e-client.h. The advantage would be that clients (like SyncEvolution) which work with both only need to implement the common operations once. Right now I have a lot of duplicate code in the address book and calendar backends. Matthew suggested to replace some of these with e_source_registry_get_default_calendar/address_book: e_cal_client_new_default() Instead do: source = e_source_registry_get_default_calendar (registry); client = e_cal_client_new (source, E_CAL_SOURCE_TYPE_EVENT, error); The same logic would apply here: instead of having separate calls for calendar and address book, have one call with an enum. BTW, in this particular example, wouldn't e_source_registry_get_default_calendar() need such an enum anyway to distinguish between default events, tasks and memos? Matthew already made a similar comment about error codes and get_capabilities. I agree that these should be common, too. I don't see why get_capabilities needs to be in ecal resp. ebook, except for the convenience wrapper functions which query specific capabilities that only apply to one or the other. Talking of capabilities, I found their usefulness a bit limited because they a) cannot change during the life time of a client and b) they only report exists/doesn't exit. Their static nature IMHO only has one benefit, which is that they can be safely cached on the client side. I don't see that as very useful, because for those capabilities which are known to be static, the client is likely to only query them once at startup and then set some internal state accordingly. Even for that the API must be asynchronous because of the underlying D-Bus call, as Matthew said. What I'd prefer is a generic key/value mechanism, with value being a string. I prefer a string because it is easy to handle and more complex types (if ever needed) can be mapped to it on a case by case basis. Setting values should also be allowed. That gives us a way how a client can configure the storage to behave in certain ways. This can be per-database (tweak the actual on-disk storage) or per EClient (modify behavior as part of current session). Future use cases for such a key/value mechanism: * change tag, read-only - a string which changes each time the database changes (same as the CTag in CalDAV), would be used to make change detection in SyncEvolution more efficient [1] * 32 bit IDs - check whether (read) or ensure that (write) IDs are 32 bit integers instead of strings, simplifies QtContacts-EDS [2]; I have a patch which reduces the size of IDs from 64 bit to 32 in the file backend, more on that in a separate email There can also be convenience functions for this, if they are considered important enough. Only adding such functions and not the generic API would have the downside that code cannot be compiled against an old API implementation and still use the new features if they happen to be available at runtime. At the D-Bus level this could be mapped to properties. [1] http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements#quick_check_for_.22data_changed.22 [2] http://lists.meego.com/pipermail/meego-dev/2011-April/482731.html -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Di, 2011-04-19 at 16:03 +0200, Milan Crha wrote:
On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
There's a couple other simple things I forgot to mention yesterday.
* We should add some padding to all the public class structs so we can
add new class methods in the future without breaking ABI. Something
like this:
struct _ECalClientClass {
... methods and stuff ...
gpointer reserved[16];
};
I never understood a need for this, neither used it when changing
structs. There was done a soname version bump when changing public
class structures, which, from my point of view, always involves also
API changes, and freezes on these both are tight together.
Are you saying that a soname version bump can and should be done in a
backwards-incompatible way (= code compiled against older version no
longer works with new lib)? That's a major pain for people trying to
support multiple distros. Please avoid it whenever possible.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Do, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote:
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote:
First of all, +1 for rethinking the API. I'd like to suggest that
besides modernizing the API we also take this opportunity to move more
of EBook/ECal into a common core.
Opening and listing databases don't have to be separate. Turn
ECalClientSourceType into EClientSourceType and all of the _new,
_new_from_uri, _new_system, _new_default, _get_sources functions can be
moved into e-client.h.
The advantage would be that clients (like SyncEvolution) which work with
both only need to implement the common operations once. Right now I have
a lot of duplicate code in the address book and calendar backends.
That's not a bad idea, actually.
It would mean EClient has to know that ECalClient and EBookClient exist
in order to instantiate the right one for a given enum value. Normally
in class design you want to avoid that kind of knowledge seeping into
lower layers, but with the class hierarchy being fixed to these three
classes (four if we add email), I think it's a good tradeoff to have a
more consistent API.
I agree, it breaks layering, but overall I'd prefer such a unified API.
So it would be something like:
typedef enum {
E_CLIENT_TYPE_ADDRESS_BOOK,
E_CLIENT_TYPE_CALENDAR,
E_CLIENT_TYPE_MEMO_LIST,
E_CLIENT_TYPE_TASK_LIST
} EClientType;
I'd prefer *our* terminology in the enum over iCalendar terminology. I
always have to stop and think okay a memo list is called a VJOURNAL
and so on.
Please, let's avoid E_CLIENT_TYPE_CALENDAR. For people less familiar
with Evolution terminology it is not clear whether this includes tasks.
In Evolution, it doesn't, but in other contexts it does. For example,
Nokia phones store events and tasks in the same Calendar. In
SyncEvolution I followed the Evolution terminology and calendar has
caused a lot of confusion.
It's not even obvious inside Evolution, because libe*cal*[endar] also
does include tasks and memos.
What about E_CLIENT_TYPE_EVENTS instead?
BTW, in this particular example, wouldn't
e_source_registry_get_default_calendar() need such an enum anyway to
distinguish between default events, tasks and memos?
I also wrote:
e_source_registry_get_default_task_list()
e_source_registry_get_default_memo_list()
http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ESourceRegistry.html
So there's four get_default functions all together. Hence why having
a single enum definition to cover them all would be nice.
Here we have the first misunderstanding because of calendar - it
wasn't obvious to me that this was exclusively for events ;-}
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] 32 bit IDs in contact file backend
Hello!
As part of wrapping QtContacts around EDS [1] I ran into the same issue
that Nokia already encountered in their Maemo 5 [2] backend: EDS uses
strings as ID, QtContacts 32 bit integers.
Nokia solved that by setting up an in-memory hash which maps the UID
string to its CRC-16. I don't see any checks for the (possible) hash
collisions. IMHO a proper solution has to keep a permanent mapping on
disk, otherwise the 32 bit IDs won't be stable.
Overall not a nice solution. My attempt to make it nicer at least in
combination with the file backend (the main goal for QtContacts-EDS)
focused on simplifying the problem instead: with 32 bit IDs in the
storage, the mapping becomes easy.
Attached the resulting patch. Note that with the patch applied, all new
contacts in a Berkley DB get the simpler IDs, unconditionally. Older
contacts continue to use their existing IDs. Would something like this
be acceptable upstream?
Further work if you agree in principle:
* let clients query whether all contacts have the simplified ID -
could be done with the dynamic capabilities that I mentioned in
the e-client API thread; avoids reading all contact (UIDs)
* optional: migrate database to simplified IDs on request
I'm not sure whether the second point really needs to be in EDS.
Obviously it should only be done when the impact on the rest of the
system is understood. For example, in a database that is synchronized
with SyncEvolution, such a rewriting of IDs will result in removing and
re-adding all contacts in the synchronized peers because that is what
it'll look like to other EDS clients.
This is also how the migration can be implemented without changes in
EDS: just remove and re-add all contacts.
[1] https://meego.gitorious.org/meego-middleware/qtcontacts-eds
[2]
https://www.qt.gitorious.org/qt-mobility/contacts/trees/master/plugins/contacts/maemo5
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
From 65438bd3c4b706535f83304d94b3c018c8899a5d Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Fri, 18 Mar 2011 16:07:23 +0100
Subject: [PATCH] addressbook file backend: use 32 bit integers as IDs
The motiviation for this change is primarily that it'll simplify
wrapping EDS in QtContacts, which only supports 32 bit integers for
the storages that it wraps.
Previously the ID was generated as a combination of time and running
counter, without checking for conflicts. This patch changes this such
that the ID is only a running counter. ID conflicts are detected during
an attempt to save, leading to retries with the next counter value.
The for future use members of _EBookBackendFilePrivate are removed
because they serve no useful purpose in a structure which is allocated
and used only locally.
---
addressbook/backends/file/e-book-backend-file.c | 48 +++---
1 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/addressbook/backends/file/e-book-backend-file.c b/addressbook/backends/file/e-book-backend-file.c
index dc6a703..d21c527 100644
--- a/addressbook/backends/file/e-book-backend-file.c
+++ b/addressbook/backends/file/e-book-backend-file.c
@@ -77,11 +77,7 @@ struct _EBookBackendFilePrivate {
DB *file_db;
DB_ENV *env;
EBookBackendSummary *summary;
- /* for future use */
- gpointer reserved1;
- gpointer reserved2;
- gpointer reserved3;
- gpointer reserved4;
+ guint id;
};
G_LOCK_DEFINE_STATIC (global_env);
@@ -169,13 +165,13 @@ build_summary (EBookBackendFilePrivate *bfpriv)
}
static gchar *
-e_book_backend_file_create_unique_id (void)
+e_book_backend_file_create_next_id (EBookBackendFile *bf)
{
- /* use a 32 counter and the 32 bit timestamp to make an id.
- it's doubtful 2^32 id's will be created in a second, so we
- should be okay. */
- static guint c = 0;
- return g_strdup_printf (PAS_ID_PREFIX %08lX%08X, time(NULL), c++);
+ /* use a 32 counter, avoid 0; collision checks must be done by caller */
+ ++bf-priv-id;
+ if (!bf-priv-id)
+ bf-priv-id = 1;
+ return g_strdup_printf (PAS_ID_PREFIX %04X, bf-priv-id);
}
static void
@@ -210,7 +206,8 @@ do_create(EBookBackendFile *bf,
g_assert (vcard_req);
g_assert (contact);
- id = e_book_backend_file_create_unique_id ();
+ retry:
+ id = e_book_backend_file_create_next_id (bf);
string_to_dbt (id, id_dbt);
@@ -224,9 +221,10 @@ do_create(EBookBackendFile *bf,
string_to_dbt (vcard, vcard_dbt);
- db_error = db-put (db, NULL, id_dbt, vcard_dbt, 0);
+ db_error = db-put (db, NULL, id_dbt, vcard_dbt, DB_NOOVERWRITE);
g_free (vcard);
+ g_free (id);
if (0 == db_error) {
db_error = db-sync (db, 0);
@@ -234,12 +232,16 @@ do_create(EBookBackendFile *bf,
g_warning (db-sync failed with %s, db_strerror (db_error));
}
} else {
- g_warning (G_STRLOC : db-put failed with %s, db_strerror (db_error));
g_object_unref (*contact);
*contact = NULL;
+ if (DB_KEYEXIST == db_error) {
+ /* did not guess a new ID, try again
Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches
On Fr, 2011-04-08 at 16:31 +0100, David Woodhouse wrote: On Fri, 2011-04-08 at 15:31 +0200, Patrick Ohly wrote: On Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote: Once this passes muster, I'll push these patches (probably *without* the NTLM bits, if you're looking closely at what I included) to the gnome-2-32 branches and perhaps start doing a 'final call' for 2.32.3 candidate bugs/patches. Please consider backporting the fixes for e_cal_new_system_*(). They are unusable in 2.32.x but I intended to use them soon in MeeGo. I'm not sure which fixed from the master branch are all needed, I hope Matthew and Milan can provide a list. I am trying hard not to bother Matthew and Milan; I don't want the continued maintenance of the gnome-2-32 branch to be a burden to them in any way. I know, but Matthew had already kindly offered some help here. I have cherry-picked the patches from master which look relevant; please could you test what is currently in http://git.infradead.org/evolution-data-server-2.32.git git://git.infradead.org/evolution-data-server-2.32.git Listing sources shows local:/system instead of local:system and opening local:system also still fails. Milan pointed to the history of e-source.c, but I don't see which (other?) commits are needed to fix these issues. -- 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches
On Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote: Once this passes muster, I'll push these patches (probably *without* the NTLM bits, if you're looking closely at what I included) to the gnome-2-32 branches and perhaps start doing a 'final call' for 2.32.3 candidate bugs/patches. Please consider backporting the fixes for e_cal_new_system_*(). They are unusable in 2.32.x but I intended to use them soon in MeeGo. I'm not sure which fixed from the master branch are all needed, I hope Matthew and Milan can provide a list. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] e_cal_new_system_calendar() - creates a new calendar each time?
Hello! I noticed that in 2.32/MeeGo, e_cal_new_system_calendar() always creates a new calendar, although there is already one. It is defined in gconf as: group uid=1300454894.7178.0@pohly-mobl1 name=On This Computer base_uri=local: readonly=nosource uid=1300454894.7178.4@pohly-mobl1 name=Personal relative_uri=system color_spec=#BECEDD//group The sequence of events is this: 1. e_cal_new_system_calendar() 2. e_cal_new_from_uri(local:system, ... 3. get source list 4. search_known_sources() by comparing e_source_peek_absolute_uri() against local:system 5. no source found, create anew Step 4 fails because there is no absolute URI: (gdb) p source-priv-absolute_uri $11 = (gchar *) 0x0 (gdb) p source-priv-relative_uri $12 = (gchar *) 0x8079450 system Therefore e_source_peek_absolute_uri() returns NULL and the comparison fails. What is the root cause for this issue, and how should it be fixed? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_new_system_calendar() - creates a new calendar each time?
On Do, 2011-04-07 at 10:47 +0200, Patrick Ohly wrote: Hello! I noticed that in 2.32/MeeGo, e_cal_new_system_calendar() always creates a new calendar, although there is already one. It is defined in gconf as: group uid=1300454894.7178.0@pohly-mobl1 name=On This Computer base_uri=local: readonly=nosource uid=1300454894.7178.4@pohly-mobl1 name=Personal relative_uri=system color_spec=#BECEDD//group The sequence of events is this: 1. e_cal_new_system_calendar() 2. e_cal_new_from_uri(local:system, ... 3. get source list 4. search_known_sources() by comparing e_source_peek_absolute_uri() against local:system 5. no source found, create anew Step 4 fails because there is no absolute URI: (gdb) p source-priv-absolute_uri $11 = (gchar *) 0x0 (gdb) p source-priv-relative_uri $12 = (gchar *) 0x8079450 system Therefore e_source_peek_absolute_uri() returns NULL and the comparison fails. What is the root cause for this issue, and how should it be fixed? absolute_uri is taken from the uri property, so adding that to the gconf sources works around the issue. Perhaps dump_common_to_xml_node() and the code after /* do not store absolute uris for local:system sources */ is to blame? Or if uri is correctly not set, then e_cal_new_system_calendar()/e_cal_new_from_uri() must be fixed to cope with that? One more oddity: on the client side, e_source_get_uri() for the system calendar returns local:/system. What is the correct absolute URI for the local system calendar? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS improvements for MeeGo
On Di, 2011-04-05 at 16:26 +0530, Chenthill Palanisamy wrote: On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote: On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly patrick.o...@gmx.de wrote: Hello! I have published some more information about our plans for MeeGo: http://wiki.meego.com/Architecture/planning/evolution-data-server http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements I was going through the eds-improvements part of it. In the performance improvement mentioned at 'Optional parsing of data in the client'. I was wondering if having a new lib[ecal/ebook] api that can return two kind of meta data, + one for populating the view [similar to message-info in mailer] + for querying the changed information [mentioned at 'change tracking+ atomic updates' section'. I don't quite follow. Can you be more specific? I was suggesting to pass the summary-info required for the view as a dbus object (which requires creation of an object similar to CamelMessageInfo) which could save string-vcard convertions and vice-versa in eds and also remove the need for delayed parsing. That would replace bandwidth-intensive send all data (as it is now) with latency-bound one D-Bus call per item. If enough meta data is sent together with the D-Bus object handle such the actual references to the objects are rarely needed, then this might help. But how would the D-Bus handle be different from reading a single contact via its UID? My feeling is that we are back to list items with UID and REV. I just noticed that e_book_get_book_view() already has a GList *requested_fields parameter. Is that used and/or implemented anywhere? The special case relevant for a QtContacts bridge would be to get just the UID. I don't think that this is covered by the current file backend, but at least the libebook/D-Bus/backend API should be in place to implement it. Ok this gives me some idea. But, use cases would make things clear. The use case for delayed parsing is the QtContacts layer on top of libebook. All the parsing/encoding would happen there. libebook just needs to pass through vcard strings unmodified. Any parsing of the vCard in libebook is just overhead in this case. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] EDS improvements for MeeGo
Hello! I have published some more information about our plans for MeeGo: http://wiki.meego.com/Architecture/planning/evolution-data-server http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements The main discussion around this takes place on meego-dev, but it would be good (and probably better) to look into the proposal also here where the upstream EDS developers hang out. Comments and help welcome ;-} -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Di, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote: For 3.1, I would like to provide a top-level header file for each of the libraries in E-D-S and deprecate including individual header files. The benefits should be clear by now: more flexibility to change or rearrange header files without breaking the public API. How much of a problem is that in practice? I have to deal with compatibility problems in all of the current releases already: * URI changes and data migration in 2.32 * account/config changes in 3.0 * and now header file changes in 3.1 If the header file change had been done such that a single = 3.0 check is enough I wouldn't mind, but it doesn't seem like 3.0 has a libebook.h (picking just one example). Is there a chance to add the headers to 3.0 before it gets released? If not, then I'd prefer to not make this change. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Mi, 2011-03-23 at 09:05 -0400, Matthew Barnes wrote: On Wed, 2011-03-23 at 13:42 +0100, Patrick Ohly wrote: How much of a problem is that in practice? It's getting to be a problem. Seemingly innocent changes to header files break builds in unexpected ways. Here's a common scenario: [...] Okay, I see your point. But if the split into individual files is merely to group code and not done to speed up compilation, wouldn't the following also work: 1. move current files into an internal sub-directory 2. introduce the new include all header 3. make all the traditional names symlinks to that one header That introduces the desired advantage (rearrange header content) without breaking the API. Is there a chance to add the headers to 3.0 before it gets released? It's too late for 3.0.0. I can add it for 3.0.1 sans the preprocessor warnings if that would help. 3.0.1 is too late to help much, unless 3.0.0 can be expected to not be used by anyone... -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Fwd: [MeeGo-dev] migration (back) to EDS]
On Mo, 2011-03-21 at 16:44 -0400, Matthew Barnes wrote: I meant to ask you when last we spoke on IRC, to what extent are you involved with MeeGo right now, and is there anyone else specifically on the MeeGo team that we should be reaching out to? My work is full-time on MeeGo. Right now I was assigned the task of proposing a plan for the migration to EDS for contacts, calendar and email. Srini stepped up and drives the email part now. David Woodhouse is also involved in email, as far as it relates to his enterprise tasks. Long-term maintenance of EDS in MeeGo is under discussion. We do have some well-known suspects at Intel, but whether they are available is a different question. I can do some exploratory work right now, but my main responsibility is for (PIM) sync and SyncEvolution, which keeps me busy enough. Help on EDS from outside might be useful, although I have no idea whether that is suitable for the tasks that I have in mind (primarily bug triaging/fixing and updates to track upstream). -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [SyncEvolution] Issues with evolution 2.32 and syncevolution 1.1.1a
Hello, update after chatting with Matthew... On Mi, 2011-02-16 at 16:59 +0100, Patrick Ohly wrote: On Mi, 2011-02-16 at 10:40 -0500, Matthew Barnes wrote: Unfortunately these keys are stuffed with XML blobs which are difficult to read in Configuration Editor, but if you scroll to the right a bit you should be able to spot the On This Computer entries. Following the name attribute there should be a base_uri attribute with a URI scheme of either file: or local:. Delete all the On This Computer entries with a base_uri=file://... attribute. *Delete* instead of *update* the entries? No, they need to be rewritten. Matthew confirmed that this happens outside of the backends, so I suspect that it is necessary to run the Evolution UI to trigger the rewriting of gconf keys. I can confirm that running the UI rewrites the keys for me. Tino, does that sound plausible to you? Does it fix your problem? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [SyncEvolution] Issues with evolution 2.32 and syncevolution 1.1.1a
.so.0 ---Type return to continue, or q return to quit--- #7 0x77662223 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #8 0x77bc9c77 in handle_method_call (connection=value optimized out, sender=value optimized out, object_path=value optimized out, interface_name=value optimized out, method_name=0x7823a960 getBook, parameters=0x7823ac60, invocation=0x78214760, user_data=0x7820ae30) at e-gdbus-egdbusbookfactory.c:383 #9 0x7792f0a0 in ?? () from /usr/lib/libgio-2.0.so.0 #10 0x7718d2e2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #11 0x771919a8 in ?? () from /lib/libglib-2.0.so.0 #12 0x77191eb5 in g_main_loop_run () from /lib/libglib-2.0.so.0 #13 0x77ffc51f in main (argc=value optimized out, argv=value optimized out) at e-data-book-factory.c:619 -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [SyncEvolution] Issues with evolution 2.32 and syncevolution 1.1.1a
On Mi, 2011-02-16 at 10:40 -0500, Matthew Barnes wrote: This change had to be accounted for in many places throughout Evolution and E-D-S and I think we missed a few in the initial 2.32 release (Milan Crha, I believe, fixed the remaining issues in 2.32.2). I ran 2.32.2 from Debian unstable. Shut down evolution, e-addressbook-factory and e-calendar-factory. Then open Applications - System Tools - Configuration Editor and check the following GConf keys for multiple entries with name=On This Computer. /apps/evolution/addressbook/sources /apps/evolution/calendar/sources /apps/evolution/memos/sources /apps/evolution/tasks/sources Unfortunately these keys are stuffed with XML blobs which are difficult to read in Configuration Editor, but if you scroll to the right a bit you should be able to spot the On This Computer entries. Following the name attribute there should be a base_uri attribute with a URI scheme of either file: or local:. Delete all the On This Computer entries with a base_uri=file://... attribute. *Delete* instead of *update* the entries? I don't have any local:// URIs in my addressbook's %gconf.xml. Here's what I have for On This Computer: stringvaluelt;?xml version=quot;1.0quot;?gt; lt;group uid=quot;1278902302.11553.20@mob-sync2quot; name=quot;On This Computerquot; base_uri=quot;file:///home/nightly/.evolution/addressbook/localquot; readonly=quot;noquot;gt;lt;source uid=quot;1278902302.11553.23@mob-sync2quot; name=quot;Personalquot; relative_uri=quot;systemquot;gt;lt;propertiesgt;lt;property name=quot;completionquot; value=quot;truequot;/gt;lt;/propertiesgt;lt;/sourcegt;lt;/groupgt; /stringvalue To me that looks like something went wrong while rewriting the gconf keys. I can fall back to the home dir before the migration and try again. Anything that I should watch out for? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Do, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: libebook - Remove e_book_new_from_uri() and e_book_get_uri(). - Remove e_book_get_addressbooks(). libecal --- - Remove e_cal_new_from_uri() and e_cal_get_uri(). - Remove e_cal_get_sources(). I must admit that I haven't read all of the emails due to lack of time. SyncEvolution uses all of these calls. I don't mind rewriting the code, but let's make sure that there is a proper replacement. What I need to do is: - list all address books and calendars - open any of the listed databases - create new ones at a location chose by the user (file://path uri in the current API) Is all of that still going to be possible? How? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Tue, 2010-10-05 at 10:41 -0400, Andrew McMillan wrote: On Tue, 2010-10-05 at 10:58 +0200, Hendrik Helwich wrote: it is possible to store your own data in the kolab format [1] (Your own XML Tags and binary mail attachments). So we could preserve the timezone information from evolution iCalendar. But we still have the problem then that the time in some recurring events could be shown different in kontact and evolution in winter or summer time even if both clients are in the same time zone. Right now i see no acceptable workaround for this problem. Hi, I'm at CalConnect XIX right now with various calendaring people, lamenting (as we usually do) just how often people seem to think that storing data in UTC means you can forget the timezone. Perhaps the CalConnect group can write a position statement on that? I wrote my own one a while ago [1] in response to discussions I had at that time with yet another one of those development teams who thought that UTC would solve the problem. But I'm sure an open letter published prominently on the CalConnect web sites would carry more weight. [1] http://www.estamos.de/blog/2008/06/30/calendar-time-stamps-and-time-zones/ -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] default calendar reminders
Hello! How is Evolution's Show a reminder some time before every appointment feature meant to be implemented? Is that something that has to be checked each time an appointment is created (in which case SyncEvolution would have to be updated) or is this a feature that applies to all existing appointments, including those without alarm set? I find the second interpretation much more useful, and not just because it would save me some trouble in SyncEvolution ;-) For example, it allows users to turn this on and off without having to edit all existing appointments. The user guide also makes is sound like it applies to all events, not just those which will be created in the future: http://docs.sun.com/app/docs/doc/817-7308/6mmkt57s1?a=view But looking at the code, I only find references to calendar-config.h's calendar_config_get_use_default_reminder() in a few places, but not in evolution/calendar/gui/alarm-notify where I would expect it to be used if it was meant to apply to all appointments. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 08:58 +0200, Milan Crha wrote: I'm working on a way to be able to report detailed errors from addressbook/calendar backends to UI, so users will be able to see something more sensible than just Other error message in Evolution. This is bug report for this [1], which I'm working on right now. Will that break libebook and libecal APIs? The issue only mentions backends, but the subject of your emails includes EBook and ECal. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote: On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote: Will that break libebook and libecal APIs? The issue only mentions backends, but the subject of your emails includes EBook and ECal. Hi, 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 this was about the synchronous APIs that SyncEvolution depends on, then I'd be really worried about this change. If those functions are not changed, SyncEvolution binaries from syncevolution.org will continue to work (full list of called functions attached). Having said that, are you sure that there is no way to preserve the old APIs? Perhaps the new implementation can be made available under a new name and the old one be implemented by mapping the GError to the old error code? I suspect that quite a few projects will have to adapt their source code if that's not the case. OpenOffice might be another candidate which tries to be binary compatible with different versions of Evolution. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ e_book_add_contact e_book_authenticate_user e_book_commit_contact e_book_error_quark e_book_get_addressbooks e_book_get_changes e_book_get_contact e_book_get_contacts e_book_get_supported_auth_methods e_book_get_uri e_book_new e_book_new_default_addressbook e_book_new_from_uri e_book_new_system_addressbook e_book_open e_book_query_any_field_contains e_book_query_unref e_book_remove_contact e_cal_add_timezone e_cal_component_get_icalcomponent e_cal_component_get_last_modified e_cal_component_get_type e_cal_create_object e_calendar_error_quark e_cal_get_component_as_string e_cal_get_object e_cal_get_object_list_as_comp e_cal_get_sources e_cal_get_timezone e_cal_get_uri e_cal_modify_object e_cal_new e_cal_new_from_uri e_cal_new_system_calendar e_cal_new_system_tasks e_cal_open e_cal_remove_object e_cal_remove_object_with_mod e_cal_set_auth_func ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On Thu, 2009-12-17 at 17:11 +0530, chen wrote: So I think we can conclude the way to go as maildir. We will also have a preference option for sharing, which will be disabled by default for the local folders in evolution. As waiters and waitresses in the US would say on such an occasion: excellent choice, sir ;-) Thanks for bringing this up and taking the feedback into account. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote: On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly patrick.o...@gmx.de wrote: On Wed, 2009-12-16 at 09:19 +0530, Chenthill wrote: On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote: On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote: * Not able to create subfolders under INBOX - https://bugzilla.gnome.org/show_bug.cgi?id=536240 . I hadn't noticed the above, so I guess it's a non-issue for me What is the second issue? Sorry missed to mention it here, with maildir we would need to rename files for unread/read flag changes which can be avoided in the later approach. So you expect renaming a file to be slower than rewriting the whole file content? Somehow my gut feeling says that it will be the other way around. But I don't have hard data, of course. I fell it will be slower compared to the other approach. You dont rewrite the file entirely at all in normal usage. Setting mail flags was mentioned as the reason for not using maildir. Adding a mail flag to an mbox mail requires rewriting the whole file. Or do you assume that you can overwrite just some bytes in an existing mail header? That will still lead to writing a complete sector to disk, in contrast to renaming a file which I expect to be implemented more intelligently by the file system. Actually, writing a micro-benchmark for this is doable. Before you seriously consider investing effort into this, I'd really prefer to see some hard data for a rename vs. rewrite comparison. May be when you expunge folder or export it, the summary data could be updated with the mail's mbox. But its debatable at some level, I would say. We are debating the merits of the actual mail storage, not the summary data. I have wiped out folders.db often enough that I won't use Evolution when it switches to storing valuable, unrecoverable information like the mail was read flag there. I definitely won't switch away from maildir as my format of choice because it integrates nicely with offlineimap. Sure, I think users should have that freedom. Camel's local folder implementation has that built in. This new approach should be the default for new users, and as option for users to migrate to it for existing users. If users willingly stay with maildir or 1mbox-per-folder that should also be there. In case it wasn't obvious, I don't see the point of diverting resources away from an established format in favor of something new. It's mbox doesn't count, you would have to write the complete directory tree handling from scratch. Of course, it is your time. I'm just expression my concerns as a user of the somewhat neglected maildir format. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On Wed, 2009-12-16 at 07:50 -0500, Matthew Barnes wrote: On Wed, 2009-12-16 at 13:18 +0100, Patrick Ohly wrote: We are debating the merits of the actual mail storage, not the summary data. I have wiped out folders.db often enough that I won't use Evolution when it switches to storing valuable, unrecoverable information like the mail was read flag there. Valuable, unrecoverable message meta-data (flags, tags, labels, etc.) should really be split off as a separate database: folders.db and, say, metadata.db. Perhaps it is just me or the way how SQLite was used so far in Evolution, but given the past experience with folders.db, I also have doubts about the reliability of such a metadata.db. I'd prefer a standard format that can be access by other tools. But you are right, in general separating the different kinds of data into different physical files is certainly an improvement over the current situation. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Failing to build latest GIT code
On Wed, 2009-11-25 at 15:05 -0500, Matthew Barnes wrote: On Wed, 2009-11-25 at 08:23 -0500, Paul Smith wrote: You will only hit this if you don't already have Evo installed. If you have it installed then the link will use the installed version. Most likely that's the problem: the linker found a different libeshell somewhere on your system. Do you know of a good way to make that more detectable for developers, short of uninstalling Evolution? On Debian, debootstrap and schroot are great for these kind of light-weight build environments that are independent of the developers personal Linux installation. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [timezone problem] Evolution calendar blew transition from CEST to CET
On Sun, 2009-10-25 at 02:27 +0100, Thomas Mittelstaedt wrote: Well, as you might know, today there was the switch from savings time to CET here in Europe. At 3 am, clocks are reset to 2 am. Well, at about 1:40 am, I entered a new event into calendar, setting the alarm notifier to 1 minute before the event. But no alarm notifier occurred. I had forgotten that the time switch was about to occur. Then I added a new event, tried to set the time using the now button, but it gave the wrong time, one hour back to the actual time. I reconfigured tzdata, checked the timezone preferences in evolution, which was set to system time. Well, finally, when it was 3 am and my system clock would make the switch as expected, evolution would behave correctly again. Seems, as if evolution doesn't make the switch at the correct time! A known bug in the system timezone to libical conversion code: https://bugzilla.gnome.org/show_bug.cgi?id=562028 Fixed by the Scalix developers recently, available in libical 0.44. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database
Hello!
Let's pick up this discussion again. When we agree on the API changes,
then I'll try to follow up with an implementation for the file backend.
On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
Hello Suman!
I forgot to ask: do you agree in general with the plan to do atomic
updates via e_book_commit_contact() and e_cal_modify_object() by
defining the semantic as suggested?
I've come to the conclusion that overloading the old calls is not worth
the trouble. Therefore I now suggest to add new variants of the call
because...
I also need to extend the proposal: removing an item has similar race
conditions (sync starts, user updates item, sync removes item). The
current APIs for removing items make it harder to pass in the expected
REV resp. LAST-MODIFIED. The only API call that could do it without
changing its prototype is e_book_async_remove_contact(EContact
*contact). e_book_remove_contact(), e_cal_remove_object(),
e_cal_remove_object_with_mod() all just take ID strings.
... we need these new variants for the delete operations anyway.
I have not looked at the calendar API yet. Let me know what you think
about the attached patch for a new ebook API and I will continue with
calendar next, before implementing anything.
In this current incarnation the patch tries a bit to provide simple
implementations of the new calls, but this isn't meant to be complete.
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
commit 86120f2c129bac4e24ea3d96c8d458ab68301414
Author: Patrick Ohly patrick.o...@gmx.de
Date: Fri Jul 24 20:08:01 2009 +0200
atomic updates and deletes: check and return revision
The current API suffers from multiple race conditions: when
overwriting a contact, another client might have already made
an update that gets overwritten by older data. Removing a
contact is also affected = added an API extension that
allows backends a) to detect that clients want the more
careful data modifications and b) provides enough information
to do the checking based on the revision string in the backend
(EBOOK_STATIC_CAPABILITY_ATOMIC_MODIFICATIONS).
Software that does change tracking based on the revision string
(like SyncEvolution) needs to know which revision string was
assigned to an updated or added contact. Currently it must do
the operation, then ask for the whole contact. There is a small
window for a race condition here, but more important, this
requires another round-trip and transmit too much information.
With EBOOK_STATIC_CAPABILITY_RETURN_REV the client can be sure
to get the necessary information right away.
diff --git a/addressbook/libebook/e-book-types.h b/addressbook/libebook/e-book-types.h
index 00a814e..2dadf27 100644
--- a/addressbook/libebook/e-book-types.h
+++ b/addressbook/libebook/e-book-types.h
@@ -64,11 +64,23 @@ typedef enum {
E_BOOK_CHANGE_CARD_MODIFIED
} EBookChangeType;
+typedef enum {
+ E_BOOK_UNDEFINED_REVISION_HANDLING = 0,
+ E_BOOK_IGNORE_REVISION = 10,
+ E_BOOK_CHECK_REVISION = 11,
+ E_BOOK_SET_REVISION = 12
+} EBookRevisionHandlingFlags;
+
typedef struct {
EBookChangeType change_type;
EContact*contact;
} EBookChange;
+typedef struct {
+ const char *id;
+ const char *rev;
+} EBookContactInstance;
+
G_END_DECLS
#endif /* ! __E_BOOK_TYPES_H__ */
diff --git a/addressbook/libebook/e-book.c b/addressbook/libebook/e-book.c
index fefe4fa..07ab5d7 100644
--- a/addressbook/libebook/e-book.c
+++ b/addressbook/libebook/e-book.c
@@ -367,7 +367,10 @@ do_add_contact (gboolean sync,
* @contact: an #EContact
* @error: a #GError to set on failure
*
- * Adds @contact to @book.
+ * Adds @contact to @book. If the backend has the
+ * #EBOOK_STATIC_CAPABILITY_RETURN_REV, then the revision string
+ * assigned to the contact is guaranteed to be set in @contact when
+ * the function returns. The UID in @contact is set in all cases.
*
* Return value: %TRUE if successful, %FALSE otherwise.
**/
@@ -393,7 +396,10 @@ e_book_add_contact (EBook *book,
* @cb: function to call when the operation finishes
* @closure: data to pass to callback function
*
- * Adds @contact to @book without blocking.
+ * Adds @contact to @book without blocking. If the backend has the
+ * #EBOOK_STATIC_CAPABILITY_RETURN_REV, then the revision string
+ * assigned to the contact is guaranteed to be set in @contact when
+ * the operation completes. The UID in @contact is set in all cases.
*
* Return value: %TRUE if the operation was started, %FALSE otherwise.
**/
@@ -476,6 +482,7 @@ e_book_response_add_contact (EBook *book,
static gboolean
do_commit_contact (gbooleansync,
+ int flags,
EBook *book,
EContact *contact,
GError**error,
@@ -487,6 +494,12 @@ do_commit_contact (gbooleansync,
CORBA_Environment ev;
char *vcard_str;
+ /* callers must decide what to do
Re: [Evolution-hackers] Command line
On Sun, 2009-03-08 at 22:04 +0100, Gilles Dartiguelongue wrote: Le vendredi 06 mars 2009 à 16:16 -0200, RASKA Maria Paula a écrit : Is there any way to use the command line for importing mbox files to Evolution instead of using the wizard it comes with? I think this is currently not possible. Also it is probably a good idea to fill a RFE at http://bugzilla.gnome.org because it would much useful for git users. In which context would that be useful for git users? Sending the patches generated with git format-patch by importing into the outbox? I have tried that once by importing manually. Without further mangling of the git format-patch output mails are then send with the send time stamp equal to the time when the patch was committed to git, which confuses recipients who sort by time. I made this mistake once and then switched to git send-email instead. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Interface Spec for PIM component interoperability
On Mon, 2009-02-16 at 13:35 +0100, Till Adam wrote: What do you guys think of a PIM BOF at the Gran Canaria desktop summit this year? I'd try to get any interested Mozillistas and Maemo-ites involved as well, if you agree that this is a good idea. Hopefully there'll be some around. Would give us all a chance to discuss the state of things and how we can best interoperate and cooperate, in the future. Sounds like a good idea. It would be a reason for me to attend. I can talk about synchronizing PIM data via SyncML and data conversion (vCard 2.1 - 3.0, vCalendar 1.0 - iCalendar 2.0). -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
