Re: [Evolution-hackers] Evolution community meeting at #evolution-meet channel - June 20 - 3:30 PM UTC
On Wed, 2012-06-20 at 15:26 -0400, Matthew Barnes wrote: > On Tue, 2012-06-19 at 16:03 +0530, Chenthill wrote: > > As some of you already know, I moved to some other project and > > spending most of my time there. At-least during the initial period, I > > would not be getting much time for evolution. Matthew would be taking > > forward the community meetings hence forth. > > We decided in today's meeting to end the monthly IRC meetings on account > of there being so few Evolution developers left. We agreed this mailing > list is sufficient and actually better suited for technical discussions, > status updates and upcoming event reminders. > > We'll hold team-wide IRC meetings as needed henceforth. > > Discussion of and consensus on this decision is posted here: > http://projects.gnome.org/evolution/meeting-logs/2012-06-20.shtml Oh I should have been there. Remembered all the time. Thought of reading a piece of new code before the meeting. It was too much to digest and slept off unknowingly.. Anyways e-h list should be ok as well given the amount of active developers. If any community members wants it, they can still ask for it. - Chenthill. > > Matthew Barnes > > ___ 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] Evolution community meeting at #evolution-meet channel - June 20 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet As some of you already know, I moved to some other project and spending most of my time there. At-least during the initial period, I would not be getting much time for evolution. Matthew would be taking forward the community meetings hence forth. Thanks, Chenthill. ___ 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] Retiring evolution-exchange
On Fri, 2012-06-01 at 06:57 -0400, Matthew Barnes wrote: > On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: > > Then why not retire evolution-mapi instead of evolution-exchange ? > > I hadn't considered that. I'll defer to Milan to make that call. > > I thought evolution-mapi worked with Exchange 2003 servers at least in > theory; I don't know how much actual testing that's had. And I know > Milan has been maintaining evo-mapi more actively than evo-exchange and > has a good working relationship with the OpenChange developers. > > In any case, maintaining this many different backends for Exchange is > ridiculous and we need to drop at least one of them given our manpower > shortage. I guess I don't care so much which, and am probably not the > most qualified to choose. > > What do you think, Milan? > > > > I do understand that you looked at the code updates and available > > developers to decide. It would also be good if we choose what to support > > based on, what would work as a good enterprise solution. I say > > enterprise since we are here talking about exchange and groupwise. > > > > W.r.t evolution-groupwise, it would be good to continue it until this > > release. I second the reason which Akhil has mentioned in another email. > > We would also need to give it sometime to see if there are people > > interested in contributing there. > > The thing is, all of these modules are going to require significant work > to adapt to the branch I'm about to merge -- groupwise perhaps even more > than the rest -- and given that I don't even have access to a GroupWise > server to test the changes I'll have to make to it, I'm highly resistant > to bothering with it if it's not going to have a full-time maintainer > going forward. > > If someone were to step forward as at least a short-term maintainer that > could help test the changes, I would reconsider. I can provide you the support. I will be getting into the new project coming Monday. I can keep myself involved during free time after a couple of weeks time.. - Chenthill. > > I will, however, release an evolution-groupwise 3.5.2 with the changes > you made recently for it. That's a fair request. > > Matthew Barnes > ___ 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] Retiring evolution-exchange
On Thu, 2012-05-24 at 16:15 -0400, Matthew Barnes wrote: > The release of Evolution-ActiveSync brings the number of Evolution Data > Server backend modules for Microsoft Exchange up to four. > > Even if we had the manpower to adequately maintain all these, which we > don't, four different backends for one product is getting ridiculous. > > Therefore I think it's time to retire Evolution-Exchange. That module > has seen steadily decreasing maintenance for several years, the newest > version of Exchange it supports is now a decade old, and frankly it was > never all that reliable anyway. > > As with any Free Software project, retiring Evolution-Exchange simply > means we will cease issuing new tarballs. 3.4.x will be its last stable > release series. Any interested party is of course welcome to resurrect > the project and issue new releases. Sorry for getting back a little late. I will include the reply with regards to evolution-groupwise as well. Though we have several packages that are supporting exchange. If we take a deeper look into what versions of exchange server they support, we might get a clear idea whether we want to retire them or not. evolution-exchange - best backend to support Exchange 2003 servers. There are some enterprises who are using evolution-exchange. As evolution-exchange has been well tested in different Exchange 2003 setups, it would be better bet over evolution-mapi. evolution-mapi, evolution-ews, evolution-activesync - all support 2007 & 2010. evolution-ews is good on desktops and evolution-activesync is good for mobile clients. We started evolution-ews considering that mapi would be deprecated in future. Then why not retire evolution-mapi instead of evolution-exchange ? I do understand that you looked at the code updates and available developers to decide. It would also be good if we choose what to support based on, what would work as a good enterprise solution. I say enterprise since we are here talking about exchange and groupwise. W.r.t evolution-groupwise, it would be good to continue it until this release. I second the reason which Akhil has mentioned in another email. We would also need to give it sometime to see if there are people interested in contributing there. Thanks, Chenthill. > If we have consensus on this I will announce it. At this time I have no > plans to adapt the module to the upcoming API changes. > > Matthew Barnes > > > > ___ > 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution community meeting at #evolution-meet channel - May 16 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] Subclassable and extendable IMAPX
On Tue, 2012-05-08 at 11:52 +0200, Christian Hilberg wrote: > Hi everyone! > > It has been a while [0] since the idea of making IMAPX > subclassable / extendable for backends to use. Time to > bring the topic back into the public again. :-) > > There is a bugzilla entry [1] now for the topic, and Chen > bravely started out with preparations to make IMAPX extendable. > > We've been staring at the imapx_untagged() function in IMAPX > for a while. This is the handler function which takes care of > processing the untagged responses from the IMAP server, and it > is the point where IMAP protocol extension code will want to > start hooking into. There may be other hooks needed. > > evolution-kolab uses IMAPX outside Evolution. Back in 2.30 era, > IMAPX was not extendable. We thus had the IMAPX code duped and > extended the hard way. Since I was overwhelmed by a single > function imapx_untagged(), approaching 1k LOC in length, I tore > it into pieces (one per untagged response) and added these into > a function table. This collapsed imapx_untagged() to almost nothing, > looking far more maintainable (and making the function extendable). > For those interested in the approach, see [2]. > > When porting evolution-kolab from 2.30 to 3.4, I decided to try > and subclass IMAPX in a clean way, since the 2.30 approach of > directly hacking my code into an IMAPX dupe would turn it into > a maintenance nightmare in the long run. > > There are two kinds of extensions to IMAPX I'm doing in evolution-kolab: > > * IMAP extensions (ANNOTATEMORE, METADATA (planned for), > IMAP ACL (planned for)) > > * Kolab extensions > > While the latter is Kolab specific, the former is not at all Kolab > specific, but holds IMAP extensions as per RFC. It therefore makes > sense to strive for integration of these extensions into upstream > IMAPX in order to have all users of IMAPX benefit from it. In the > evolution-kolab source tree, the former resides in > > src/camel/providers/imapx > > while the latter resides in > > src/camel > > to make the distinction clear. There are a number of CamelIMAPXExtd* > classes I've added to src/camel/providers/imapx which hold my > extensions over the upstream IMAPX (the upstream files are duped with > just minor changes, mostly exposing internal API for me to hook into). > Please see [3] for the stretches I needed to make to subclass IMAPX. > Main problem was that imapx_untagged() was not exposed, so I had to > re-implement all code paths to that function inside my own extended > classes. To ensure I would get my extended object types in the right > places, I had to override the CamelIMAPXConnManager classes with my > own, mainly because the IMAPX internal classes were not using virtualized > functions (which made it impossible for me to just inject my types here > and there - I had to make sure the right code paths were followed). > The classes in src/camel (thr Kolab-specific ones) look somewhat alike, > for that same reason, see [4]. > > I've not been diving into Chen's proposals very deeply yet. Allowing > subclasses to override imapx_untagged() seems like the first step. I've > not yet grokked all of the proposals, so I have a question: Will the > current proposal (see [1]) allow for a subclassed IMAPX to be subclassed > again? Subclassing IMAPX twice is what I'm doing in evolution-kolab. > Of course, the first subclassing (for adding support for folder metadata > and ACL) can just be dropped, once these extensions make it into > upstream subclassable IMAPX. > > Then, there's my table-based approach to imapx_untagged(). I've been > having a chat with Matt about that (and back in the days when I did the > implementation for 2.30, with David), which both liked the idea. Of course, > my 2.30 implementation was not done with truly subclassing IMAPX in mind, > so it would need some tweaking. I'll try to gather more thoughts as I'm > rovelling through the code of the proposal at BZ. > > What do you think? > > I would invite everyone who is hacking IMAPX to participate in this > discussion. I hope you had sent the mail just before our irc discussion. To summarize, https://bugzilla.gnome.org/show_bug.cgi?id=674310#c9 has the fixes. We now have a hook in imapx_untagged which would allow the subclasses to handle the responses that are not handled in IMAP (imapx provider). I did not find a case where a sub-classed imap provider would be interested in tags which are already processed by the parent imap provider, so i have provided a simple hook to handle, unhandled tags. I hope this would be sufficient to support all the above needs. Please let me know if you need anything more..
[Evolution-hackers] Evolution community meeting at #evolution-meet channel - April 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] Memory corruption in timezone handling
On Tue, 2012-04-03 at 17:57 +0200, Christian Hilberg wrote: > Hi, > > Am Sonntag 01 April 2012, um 11:13:00 schrieb Robie Basak: > > Hi freeassociation-devel, > > > > I think I've tracked down a segfault in evolution to a bug in libical. > > > > In icaltimezone.c:icaltimezone_get_builtin_timezone, > > icalarray_append(builtin_timezones, ...) is called. This can cause > > icalarray_expand() to be called, moving the entire builtin_timezones > > array and thus invalidating any previous pointers into the array. > > [...] > > A follow-up on the freeassociation-devel list asks whether Evo/E-D-S > still use a local fork of libical or whether they're using upstream > libical. From what the sources and configure.ac tell me, it is the latter. > > I guess we should communicate this to freeassociation-devel? We moved to upstream libical long time back - https://bugzilla.gnome.org/show_bug.cgi?id=541209 . - Chenthill. > > > Kind regards, > > Christian > > ___ > 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 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] WebKit branch is ready
On Wed, 2012-03-28 at 16:26 +0200, Dan Vratil wrote: > On Wednesday 28 of March 2012 17:59:27 you wrote: > > On Wed, Mar 28, 2012 at 4:13 PM, Daniel Vratil wrote: > > > Hello everyone! > > > > > > WebKitGtk+ 1.8.0 with the important patch has been released last night, > > > and so everything is in place now and I'm ready to break^W merge to > > > master. The branch has been rebased two days ago, I will only bump the > > > webkit dependency version later today. > > > > > > I hereby ask you guys for review and approval for the merge. > > > > This is great news. Im just so excited to try things out for 3.5.x. Do > > you have webkit for composer too? > > Hi, > > only email reader is done so far, I will start hacking on composer now. I > have > quite a lot of time till 3.6 and hopefully the composer won't take as much > time as the reader did, so if things go well, we could kill GtkHtml for good > in 3.6 after all :) Wonderful!!! - Chenthill. > > Dan > > > > > -Srini. > > > > > I'd suggest creating 4 or 5 new commits directly in master instead of > > > actual git merge to avoid polluting master history with nearly 200 > > > commits of my furious development :) > > > > > > Cheers, > > > > > > Dan > > > ___ > > > 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 mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ 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] Evolution community meeting at #evolution-meet channel - Mar 21 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] Home news from the Evo/WebKit Universe
On Thu, 2012-02-09 at 09:09 -0600, Matthew Barnes wrote: > On Thu, 2012-02-09 at 12:12 +0100, Dan Vratil wrote: > > just a short note - thanks to Milan who has decied to dig into WebKit, > > embedding widgets into WebKit webview works again. > > That's awesome news! I think I suffered that same bug early on in the > branch. Nearly drove myself crazy trying to get a simple embedded icon > to draw. > > Well done to both of you! +1 :) - Chenthill. > > Matt > > ___ > 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution community meeting at #evolution-meet channel - Feb 15 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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 11:44 +0100, Milan Crha wrote: > On Tue, 2012-02-14 at 11:20 +0100, Patrick Ohly wrote: > > 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? > > Hi, > I do not know how the idea of only_if_exists begun, it predates me. > The current behavior depends on each backend, some, like those remote, > doesn't count with it at all (like for the webcal backend, it cannot > create remote calendars, thus it always either fail or succeed, based on > the existence of the remote calendar). > > I left it there when changing API due to EClient changes, because it > seemed to me that someone can find it useful, say with local, non-system > calendars. But maybe not. > > It will be good to have opinion from other team members, either former > or current. These are used atm for operations such as copy-to-calendar or while changing the calendar from the event-page. My guess is that it could have been introduced to avoid opening the calendar unless its already opened to avoid any UI in-responsiveness. IMHO that option can be removed and the async api's can be used to solve it unless there is some other case. - Chenthill. > Bye, > Milan > > ___ > 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Jan 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Dec 21 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] Camel no longer depends on libedataserver
On Wed, 2011-11-16 at 15:38 -0500, Matthew Barnes wrote: > On Mon, 2011-11-14 at 23:33 -0500, Matthew Barnes wrote: > > There is no longer any _technical_ reason why Camel needs to be bundled > > in the evolution-data-server module. I DO intend to split Camel off at > > some point, but not yet. Parts of its API are still a complete mess and > > I'd like to give them some attention and also reach some semblance of > > API stability for the library as a whole. We're not there yet. > > Chen asked me in the IRC meeting today [1] to clarify my position on > splitting off Camel. > > My vision for Camel is simply for it to be a nicely crafted, reusable, > well-documented mail client library with tight GIO integration. I do > believe that's in line with what it was intended for all along. > > But as long as it stays arbitrarily bundled in E-D-S it's not really > reusable. Any project looking to use such a library would be scared > away by having to drag in E-D-S for no reason. And I want Camel to > be a viable choice. [2] > > Picking up just one additional user besides Evolution, like perhaps > something from the XFCE or LXDE projects, would be really healthy for > Camel. It would demonstrate that Camel _is_ reusable. It would force > us to consider other users of Camel before making changes. That's a > good thing. It's a sign of library maturity. > > Camel is a base library for E-D-S. Always has been, for as long as I've > been around anyway. We already treat it as a base library. Splitting > Camel out of the E-D-S git repo would have minimal impact. In concrete > terms, it would involve moving the "camel" source directory, its API > docs, and some autoconf goo to a separate git repo. Then we would start > releasing Camel tarballs. That's it. Aside from maybe some pkg-config > tweaks there would be ZERO impact to Evolution or the extension modules. > > [It occurred to me that we would first need to give Camel the ability to > load provider modules from both built-in and custom directories, so the > evo-specific providers stay evo-specific. IMAPX, POP, SMTP, etc. would > move perhaps to /usr/lib/camel/providers; but MAPI, EWS, GroupWise, etc. > would stay where they are. Perhaps that's where the resistance is > coming from? That's an easy fix.] > > Let me emphasize again that Camel is not yet ready to be split off from > E-D-S. This is a long term goal, and in fact I've been nudging Camel in > this direction for years. Porting Camel to GObject, sealing up object > structures, moving to a single-include paradigm like GTK+ did, adding an > asynchronous API, keeping its API docs up-to-date, and now severing its > libedataserver dependency... all done in the service of molding Camel > into a standalone GLib-based mail library. > > I think an actual split is probably a year or two out yet, at least. > Splitting off Camel now would create API stability expectations that I'm > not ready to meet. Parts of Camel's API still need a lot of love, and > sheltering the library in the E-D-S repo for the time being gives us > cover to break the API to fix it, until everything is hammered into > shape and nicely polished. Camel is still "in the shop", so to speak. > > I view the split as just a logical step in Camel's path to maturity, so > I was a bit taken aback by the resistance expressed. Hopefully I've now > clarified myself. Thanks for a detailed explanation. Rather than calling resistance, i would say everyone wanted a clarity :) My concern is that, the above stated reasoning would hold good for libebook and libecal as well. But I think it might be too early to discuss this, later. Thanks, Chenthill. > > Matthew Barnes > > > [1] http://projects.gnome.org/evolution/meeting-logs/2011-11-16.shtml > > [2] Some distros like Debian already package Camel as a standalone > library. "apt-get install libcamel-1.2-23" Perhaps the point > to all my rambling is it should be packaged this way UPSTREAM > too. > > > ___ > 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 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 Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: > Hello! > > I'd like to write down some thoughts on vCard UID handling in EDS. > Andrew mentioned it on IRC, so I'm copying him. > > Let me define the terms to make the difference clear: > * UID: part of the contact properties. Ideally set once when a new > contact is created in such a way that it is globally unique > (same semantic as iCalendar 2.0 UID, not just unique inside the > current address book). Can and should be passed around and > preserved when exporting/importing contacts. > * local ID: local meta data about a contact, only relevant inside > an address book to look up contacts. > > The current situation is that EDS uses the vCard UID property for its > own local ID. When trying to create a new contact with UID already set, > that UID will be overwritten. > > This is problematic for interoperability (one cannot store a vCard > as-is) and syncing (which would benefit considerably from a > creator-assigned, fixed UID). > > This is partly an API and partly an implementation issue. The > libebook<->e_addressbook_factory D-Bus API just passes vCards, so a > vCard property has to be used for any local ID, and UID is the one that > is used. > > e_book_add_contact() doesn't have an explicit "local ID" retval. Clients > have to use e_contact_get_const(contact, E_CONTACT_UID) to retrieve the > assigned local ID. Other APIs avoid that. For example, > e_book_add_contact_async() + EBookIdAsyncCallback return the ID > out-of-band. > > The more recent EBookClient API always uses separate ID retvals. > However, in contrast to the EBook API it specifies that these are the > UID of the created contact and not some kind of local ID. The older API > left that undefined and just talked of "id". > > I see several ways forward: > 1. Accept that a contact ID as used in the EBook API is the vCard > UID and make it possible to set that UID when creating a new > contact. That implies for adding a contact: > * remove the code which overwrites the UID > * add check for existence of the UID in the address book > and a corresponding error code if it does > 2. Use the local ID in the EBook API and support storing the vCard > UID separately. Support lookup of a contact by UID. > > The advantage of the second approach is that it is potentially more > efficient. I myself took advantage of that in the EDS<->QtContacts > bridge code. But it never was a full solution (depended on 32 bit local > IDs, which is okay for the file backend, but not all of them, and > required patching EDS). > > The disadvantage of the second approach is an API change and/or > extension. It has some potential advantages, but as the EDS<->QtContacts > bridge is not used anymore, there is little incentive to do the extra > work right away. > > 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. Just went through the thread and had a small discussion with mcrha. My preference goes with the first approach along with having the static capability. - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Nov 16 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] Can I remove some old migration cruft, pretty please?
On Tue, 2011-11-08 at 07:34 +0100, Milan Crha wrote: > On Mon, 2011-11-07 at 16:21 -0500, Matthew Barnes wrote: > > Users upgrading from versions 2.22 or older will just have to regenerate > > their mail caches from scratch. I don't think that's unreasonable. > > Hi, > probably the only thing is with local providers, users will loose their > labels and other custom tags/flags on messages. I do not take it as an > objection, though, the migration process used to crash or freeze anyway. > You've a green from me. Sounds fine for me as well. - Chenthill. > Bye, > Milan > > ___ > 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 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] Since evolution-alarm-notify asks for passwords
On Wed, 2011-10-19 at 08:24 +0200, Milan Crha wrote: > Hi, > I cannot find the thread where this was discussed, I'm sorry, but after > few days I found why this behaviour is pretty bad and why the > evolution-alarm-notify didn't ask for passwords. My usecase is pretty > simple, and I believe there are many corporate users with the same > environment: I have entered few calendars which are accessed only when > I'm connected to company vpn, unless they fail. When I login I do not > have the vpn running, thus I'm asked for my passwords, thus I connect to > vpn and then enter it (it's not prefilled, because it's not a reprompt, > though maybe some little change on evolution-mapi could be done - these > are evo-mapi calendars). > > My question is whether there can be done any better way of coping with > this, because having the password prompts (there are two pilled, > actually) after each and every login is just a bad experience, from my > point of view. Would it not be possible to store the password in gnome-keyring and be shared. The other providers work this way, alarm-daemon would start the authenticated calendars if it finds that the passwords is stored gnome-keyring. It would also check whether the password can be retrieved between intervals AFAICR. In case a calendar is marked for alarms and if alarm-daemon was not able to retrieve the password, would it be a good idea to show a small warning icon in the panel, which could indicate the issue and mention that evolution needs to be started in order to retrieve the password ? Also inform the user that the password needs to be remembered for alarm-daemon to work fine. > Bye, > Milan > > P.S.: Most likely unrelated, but I see I'm asked for Tasks and Notes > passwords, at least based on the prompts, which should not be needed in > the evolution-alarm-notify, because evolution doesn't support alarms on > these. I dont think the earlier behaviour used to be like this. This should be a bug introduced at some state IMHO. - Chenthill. > > ___ > 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 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] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 19 - 3:30 PM UTC
On Tue, 2011-10-18 at 12:30 +0200, Christian Hilberg wrote: > Hi Chen, > > Am Dienstag 18 Oktober 2011, um 12:13:04 schrieb Chenthill: > > Hi, > > The meeting goes as follows, > > [...] > > You sure the meeting is *today*, not tomorrow (i.e. Wednesday), > as usual? Just asking. :-) Oh my bad, not again. Its tomorrow - oct 19 :) Thanks for pointing!! - Chenthill. > > > (Bye)^2, > > Christian > > ___ > 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Sep 21 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - July 20 - 3:30 PM UTC
On Tue, 2011-07-19 at 11:17 +0530, Chenthill wrote: > Hi, > The meeting goes as follows, > > * Project updates > * Discussion on queries/decisions > * Individual updates Postponing the meeting to next week Wednesday (July 27) as some hackers wont be available today.. Thanks, Chenthill. > > - Chenthill. > > ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - July 20 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ 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 10:48 +0200, Patrick Ohly wrote: > 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. 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 ? - Chenthill. > > > 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. > ___ 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] towards Upstream-Integration
On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: > Hi everyone. > > Since the last announcement of the evolution-kolab team here on the list, our > source code (hosted at http://evolution-kolab.sourceforge.net/) has seen some > more polishing and now compiles on Debian/Squeeze in addition to > Ubuntu/Lucid. > We will make available a (source) release 0.0.13 soon, which contains the > fixes for Squeeze. > Next week will see some performance improvements over the current state, > and > by the end of next week, I am planning to have the post-0.0.13 release ready. > > The code base has received quite some testing (under Ubuntu/Lucid) already, > mainly in the area of Kolab inter-client compatibility. Online and offline > operational modes are working, including conflict resolution. More testing is > always welcome, of course. > > The evolution-kolab team now feels that we have reached a state where we can > begin working towards upstream integration. During the planning and coding > phases so far, we aligned all of our project decisions with the Evolution > team > as closely as our time schedule and resources permitted. This was done in > order to promote for an easy upstream integration process. We would like to > thank everyone here who helped us in the various aspects of creating a new > Evolution plugin. > > We would very much like to be hosted at gnome.org with our project. > SourceForge is a nice breeding platform, but we feel it is a little too far > away from GNOME, and since we are a true GNOME project, we think it would be > nice to add evolution-kolab directly to the Evolution project at its GNOME > site. > > The first step could be to create an evolution-kolab git repository at > gnome.org, at least this is what came to my mind instantly. In order to get > the prerequisites right, I have applied for a GNOME account with git access. > This has been vouched for by the Evolution team (thanks, Matt), and I have > received confirmation from the GNOME account management team today. > > Since neither my kernel concepts evolution-kolab team mates nor myself have > done upstream integration for an Evolution plugin yet, I would like to know > how we should best proceed from here. If there is any reading we should have > done prior to further acting, we'll gladly accept pointers to the relevant > documents. David (or anyone else involved there), I heard that you did the > same with your EWS team recently, so if there are any lessons-learned which > we > should heed to, we will also be happy to know. Long story short, we will just > be happy for any directing through this process so we can get through it > smoothly. You could create a package naming eg: evolution-kolab and create a new repository in git.gnome.org. http://live.gnome.org/Git/NewRepository has all the details required. Thanks, Chenthill. > > Thanks a lot in advance, > Kind regards, > > Christian > > > ___ > 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 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] evolution-ews: implement Exchange categories as evolution labels (read only)
On Mon, 2011-05-23 at 16:01 +0100, David Woodhouse wrote: > On Mon, 2011-05-23 at 17:46 +0400, James Bottomley wrote: > > I think you probably need me to get a feel for evolution development > > initially before you set me loose in the repo ... > > Why? It's mostly my baby, and I'm a kernel hacker too... :) > > > Incidentally, I presume you use bugzilla for bugs? I just ran across > > one experimenting with Categories. Apparently if I change the category > > on the outlook webserver, it causes us to delete the email (with or > > without my patch applied). > > That'll be a bug that Chen introduced on Thursday. I've reverted those > commits for now. We're currently between Alpha and Beta releases; I > don't mind a little bit of 'churn', but I draw the line at data loss :) > > Sorry about that. Sorry for it, its a bad assumption I made. Fixed it in master. - Chenthill. > > Note that HEAD doesn't compile at the moment because of something > committed by Pavel Ocheretny last night. > I'll change that to a real, working email address and *POKE*. > ___ 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] Indexing of mail body? how it works?
On Fri, 2011-05-20 at 13:27 +0200, Nicolas Michel wrote: > Hello, > > I had used Ubuntu for some years. Some weeks ago when gnome 3 was > realesed I decided to switch to Archlinux. > So I'm now with archlinux 64 bits - gnome 3 with gnome-shell and > Evolution 3.0.1-1. > > A search on body-content is very very slow. > > I have to say that I have a hudge INBOX : ~18500 mails (but it was not a > problem on Ubuntu). > > So here are my questions : > - is it because of the Evolution package on Ubuntu is patch with > something from canonical that increase the speed of search on body content? > > - is it because of the newer version of Evolution? (3.0.1-1 on Archlinx > insted of 2.30 on the last Ubuntu I tested on) > > - In that latest case, is it a regression and if yes, will you fix it? > > - Or maybe I only have to install another package that will index my > Evolution's mail? > > My only purpose is to be able to make search on body content as fast as > I did on Ubuntu. Even with 18500 mails, such a search took only a few > seconds on Ubuntu (2,3 or 4 seconds ; now on arch it takes 30-40 or 50 > seconds). Are your mails stored in local system folders or are they local folders stored as mbox or maildir or do you have them on some server, cached them using imap or pop ? - Chenthill. > > Many many thanks! > Nicolas. > ___ > 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 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 Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote: > 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? Well, if you were thinking on supporting all backends using Qtcontacts, it is never a solution. I suggested looking at the initial patch attached, which meant only for file backend. Changing the ids to use 32 bit ids just for file backend also becomes irrelevant if the intention is to support all backends, as its clear that servers like exchange/groupwise create uids as strings which cannot be controlled by eds. > Quite frankly, patching the existing backends sounds less > risky to me. Of course, including these changes upstream would be best. I agree, but we need to find a better solution than the one which is proposed to suit all backend's. - Chenthill. ___ 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 Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote: > On Di, 2011-05-17 at 13:27 +0100, David Woodhouse wrote: > > On Tue, 2011-05-17 at 14:04 +0200, Patrick Ohly wrote: > > > On Di, 2011-05-17 at 12:38 +0100, David Woodhouse wrote: > > > > Even if we *didn't* have immediate plans to use other back ends like EWS > > > > with this setup, that would be entirely the wrong thing to do, surely? > > > > > > I'm not so sure. We are pitching EDS as an alternative for other storage > > > solutions that are highly optimized (= limited!) for specific use cases. > > > What you are suggesting is that any attempt to add optimizations for a > > > specific combination of app + EDS + backend is wrong and should be > > > avoided. My feeling is that EDS will simply not be used at all unless > > > such optimization are acceptable. > > > > [EDS upstream] > > > > I have no objection to an *optimisation*. You seemed to be describing a > > *fix*, not an optimisation. > > > > An *optimisation* allows things to work faster or more efficiently, when > > they were already working before. > > > > So if you expose an extra '32bit-numeric-uid' in your static > > capabilities for the back end, and the user can make use of that to > > operate more efficiently by bypassing the permanent uidstring<->integer > > mapping, then I'm happy with that. > > That was the plan. From the original email: > > | 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 was for a moment confused on this and david's reply was right on target :) 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 ? - Chenthill. > > But *only* if it really is an > > optimisation, and designed such that the code still works (via the > > mapping) without it. > > I can't promise that the code will work without it right away because > the mapping hasn't been implemented yet due to lack of time. See also: > http://lists.meego.com/pipermail/meego-dev/2011-May/483078.html > > ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - May 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Check out http://live.gnome.org/Evolution/CommunityMeet for more details. - Chenthill. ___ 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] EBookBackendSqliteDB comments
On Fri, 2011-05-06 at 08:56 +0200, Milan Crha wrote: > (Please do not reply to me, reply to the list, I read the list and I > prefer to Ctrl+L while your message avoids this feature for me. Thanks > for your understanding.) > > On Thu, 2011-05-05 at 12:23 +0530, Chenthill wrote: > > > you scary me. Could you repeat where is written information about a > > > design you chose for this, how it correlates with actual backend > > > cache(s) (we do not want to loose functionality here) and maybe why done > > > so? > > Well, I have not started on the meta-data storage yet :) Just have a > > table for it. There is no specific design for it. > > Hi, > my above question wasn't only about meta-data, it was a general question > "what are you doing and how are you doing that". Without that answered > it's just confusing. I will appreciate something like "we have now these > options, storing these values... and we will have it changed to this > which will be doing this and this". I believe you have it somewhere > done, I only didn't notice where. I'm sorry for that. > > For example, you mentioned once that there should be benefical to use > only summary columns to be returned for some cases, like autocomplete, > which doesn't require fully populated contacts. It makes sense from my > point of view and I will add > > e_book_client_view_set_restriction_fields_sync (..., const GSList > *fields_to_fetch, ...) > > which will set list of field names to be fetched only on a view. Yup that is possible. This would also need another column mentioning whether the contact is fully cached or not, will add the same. > > Another thing, I do not understand much why we are talking about XML > here. Why to combine two approaches when you have one already, the > database? Though of course, if it's just meant that the key-value pair > can store (the value part) just anything the caller wants, then yes, I'm > all fine with it. Its just about the key-value pairs. > > > I recall us chatting about this on IRC or somewhere one day and one > > > point was that the contacts will not be stored in a binary form, but > > > rather as separate files. What Sean wrote earlier sounds like you > > > changed your mind in this point. I do not think it's a good idea, see > > > how often the sqlite folders.db file in camel is broken, and users are > > > adviced to delete it. Will they loose all their contacts in such > > > situation? > > As I already said seanus on irc, I will be evaluating the performance > > between having vcards as files Vs having it in db and then choose the > > one which would be best. So the code for both will be there and we can > > choose between them over after testing. I was also thinking of providing > > it as an option for the backends to choose once i complete the testing.. > > So what we discussed stays the same :) > > This is not only about performance, my main concerns are these: > a) if something fails with db file, user's data are safe > b) users can take their contacts anytime and import them on another > machine, in case of hard disk crash, partial backup or anything like > that I hope seanus's reply addresses this. For remote address-book's if db is corrupt, the local keys like 'last-modified' time would be lost, so we would anyways cache all the data again even if the vcards might be there to ensure that we are in sync with the server. I will check the performance impact and if there is no big difference, will go for storing them as separate files. If there is a considerable difference, will provide options for both. > c) folders.db files tend to grow "indefinitely". That's another point > why I do not like "one file per account". [i missed say this in the previous reply to seanus, so just adding it here] My idea here was to make it configurable, so that all personal address-books can use one file and a relatively bigger address-book like GAL can use a separate db file. http://git.gnome.org/browse/evolution-ews/tree/src/addressbook/e-book-backend-sqlitedb.h Rest I hope I have answered in another reply to seanus. - Chenthill. > > An example: my evo-mapi account has 4 addressbooks (one is GAL). I would > really prefer to have them separated, not in one large file. Not talking > about possible (even unlikely) UID clashes between separate > addressbooks. Will it also mean that each local addressbook will be > stored in one large db? Please do not do that. > > As I said in the very beginning, I still do not see what you are doing > and how; it might be a good time to open the code and check that out :) &g
Re: [Evolution-hackers] EBookBackendSqliteDB comments
mily_name TEXT, \
> email_1 TEXT, email_2 TEXT, \
> email_3 TEXT, email_4 TEXT, \
> vcard TEXT)", folderid);
>
> which AIUI means a table named after every folder. Therefore the UID's
> are already internally partitioned and will not conflict. WRT normalizing
> the database, I would suggest something more like:
>
> const gchar *stmt = "CREATE TABLE IF NOT EXISTS folders \
>( folder_id TEXT PRIMARY KEY,
> \
> folder_name TEXT,
> \
> sync_data TEXT,
> \
> bdata1 TEXT, bdata2 TEXT,
> \
> bdata3 TEXT)";
>
> stmt = sqlite3_mprintf ("CREATE TABLE IF NOT EXISTS contacts
> \
> ( folder_id INT,
> uid TEXT, \
> nickname TEXT, full_name TEXT, \
> given_name TEXT, family_name TEXT, \
> email_1 TEXT, email_2 TEXT, \
> email_3 TEXT, email_4 TEXT, \
> vcard TEXT,
> PRIMARY KEY (folder_id, uid) )" );
>
On address-book deletion, dropping a table is far better than querying
and deleting all the contacts that matches a folder id. But the
frequency of deleting address-book's may be less.
So I went for a quick search and found this,
http://stackoverflow.com/questions/784173/what-are-the-performance-characteristics-of-sqlite-with-very-large-database-files
which shows using mutltiple tables is better. I have not personally done
any tests regarding this.
> As an extra bonus that means you could do autocomplete type
> queries in a single SQL query.
AFAIK with the current design of eds, each address-book would be queried
separately and would not benefit by this.
- Chenthill.
>
>
>
> sean
> ___
> 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 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] EBookBackendSqliteDB comments
On Thu, 2011-05-05 at 14:49 +0200, sean finney wrote: > On Thu, May 05, 2011 at 12:23:01PM +0530, Chenthill wrote: > > > Be sure that parsing bdata is a pain, and always will, > > > especially when you already are in a database world, where are tables > > > and relations between them pretty common and nature. > > This is the reason I was thinking whether it would be good idea to have > > a abstract API to store extended (apart from sync_data, populated > > columns etc.) key-value pairs if the backend needs. This can form the > > xml and store it as bdata. Now the bdata would not be exposed to the > > callers. Is there any other better way to do this ? > > Forgive the rusty SQL, but assuming you have a single db with > multiple folders in it, soemthing like: > > create table folder_kvdata ( > folder_id_id int foreign key references folders(folder_id), > keyname text, > keyval text > ); > > ? With this it would be pretty trivial to fetch single values > as well as enumerate/update/delete all keys/values for a folder. > If the caller needed something more complicated than a single value, > an xml object or whatever else could be embedded on an as-needed basis. This is far better. Would get it done this way. - Chenthill. > > > > If I recall correctly then "populated" and "last_modified" were also > > > stored as keys in the background, but backend could drop them > > > accidentally, when accessing through keys "directly". It sometimes can > > > be considered a benefit, but it usually isn't. If I have specialized API > > > to access these keys, then I should use it exclusively. I think. > > For the commonly used keys such as the above we would have specialized > > API's and they would be having separate columns on a per-folder basis. > > yeah, I think it would be a good idea to claerly break them out from > the "general" k/v pairs, to avoid conflicts and special-casing any code. > > > > I recall us chatting about this on IRC or somewhere one day and one > > > point was that the contacts will not be stored in a binary form, but > > > rather as separate files. What Sean wrote earlier sounds like you > > > changed your mind in this point. I do not think it's a good idea, see > > > how often the sqlite folders.db file in camel is broken, and users are > > > adviced to delete it. Will they loose all their contacts in such > > > situation? > > As I already said seanus on irc, I will be evaluating the performance > > between having vcards as files Vs having it in db and then choose the > > one which would be best. So the code for both will be there and we can > > choose between them over after testing. I was also thinking of providing > > it as an option for the backends to choose once i complete the testing.. > > So what we discussed stays the same :) > > W.r.t. a performance standpoint, I will be testing against a Global > Address List of somewhere around 60k entries, so that should give a > pretty good idea :) > > I think Milan also had concerns with regards to "stability/fragility", > with corrupting databases, etc. But I don't think that the "split out" > option is immune from these types of problems as well (and there may be > even further problems, since we would be home-rolling that solution as > opposed to relying on a well tested API/DB). > > > sean ___ 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] EBookBackendSqliteDB comments
On Thu, 2011-05-05 at 13:53 +0200, Milan Crha wrote: > On Thu, 2011-05-05 at 11:20 +0530, Chenthill wrote: > > > * if folder metadata is going to be free-form, it could be better > > >to have a key->value table ( folder_id_id int, key_name text, > > >value text > ) rather than arbitrarily numbered text/binary > > >fields. > > I was thinking of allowing the backends to store key value pairs using > > a bdata column which could be populated with xml key-value data. Would > > be it be good idea ? > > Hi, > you scary me. Could you repeat where is written information about a > design you chose for this, how it correlates with actual backend > cache(s) (we do not want to loose functionality here) and maybe why done > so? Well, I have not started on the meta-data storage yet :) Just have a table for it. There is no specific design for it. > > Like in the above quoted text, is that to replace keys.xml file (it's > from calendar, I know, but you know what I mean)? Or what do you call > meta-data? In calendar terms, yes. > I want to be able to store my own keys per account (not per > item, it's another thing which scary me, one addressbook cache file per > account, really?) Meta-data table is one for an account and folder meta-bata will form the rows. > Be sure that parsing bdata is a pain, and always will, > especially when you already are in a database world, where are tables > and relations between them pretty common and nature. This is the reason I was thinking whether it would be good idea to have a abstract API to store extended (apart from sync_data, populated columns etc.) key-value pairs if the backend needs. This can form the xml and store it as bdata. Now the bdata would not be exposed to the callers. Is there any other better way to do this ? > > If I recall correctly then "populated" and "last_modified" were also > stored as keys in the background, but backend could drop them > accidentally, when accessing through keys "directly". It sometimes can > be considered a benefit, but it usually isn't. If I have specialized API > to access these keys, then I should use it exclusively. I think. For the commonly used keys such as the above we would have specialized API's and they would be having separate columns on a per-folder basis. > I recall us chatting about this on IRC or somewhere one day and one > point was that the contacts will not be stored in a binary form, but > rather as separate files. What Sean wrote earlier sounds like you > changed your mind in this point. I do not think it's a good idea, see > how often the sqlite folders.db file in camel is broken, and users are > adviced to delete it. Will they loose all their contacts in such > situation? As I already said seanus on irc, I will be evaluating the performance between having vcards as files Vs having it in db and then choose the one which would be best. So the code for both will be there and we can choose between them over after testing. I was also thinking of providing it as an option for the backends to choose once i complete the testing.. So what we discussed stays the same :) - Chenthill. > Bye, > Milan > > P.S.: I confess I didn't open your code, I only read this thread. > > ___ > 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 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] EBookBackendSqliteDB comments
On Thu, 2011-05-05 at 11:20 +0530, Chenthill wrote: > > > * not sure of this one: given there may be multithreaded access to > the db, > >do we need to provide any external "big locks" on reads/writes? > maybe Though sqlite has it, i have read in the FAQ that it recommends applications not to perform any read operation while a write is in place. And I did not want to our app to loop of _BUSY message, so I have added a RW lock to avoid that. - Chenthill. ___ 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] EBookBackendSqliteDB comments
On Wed, 2011-05-04 at 13:04 +0200, sean finney wrote: > Hi Everyone, > > I spoke with chen on IRC this morning and got hinted at a preliminary > implementation of EBookBackendSqliteDB sitting in -ews. Since there > are some benefits of something something like this make it's way to > a common place that could be used by -mapi as well, I thought I'd do > a quick feasability review to see what problems there might be. > > Questions/commments/suggestions follow. Please let me know what you > think! > > * No backend _get_contact/_get_contacts equivalent. Should be >easily implemented. _get_vcard_string ==> _get_contact, i have not added an API return EContact to let the callers decide whether they want to parse the string to EContact. i have not observed any use cases for get_contacts needed by the backends. _book_backend_sqlitedb_search would server the _get_contact_list API in the backend and also for querying using a search query to fetch the contact list. > * _add_contact/_remove_contact should be renamed to >_add_contacts/_remove_contacts to be consistant with other backend >methods that take lists. Makes sense as it already acts on multiple contacts. > * but also having a _add_contact/_remove_contact that takes just a uid >(similar to other backends) would be useful remove_contacts already takes only uid. I do not know how far _add_contact with just the uid would be helpful. Which backend would need it ? > * -mapi seems to use one cache per-profile-per-folder, but the sqlitedb >backend takes these as calling parameters. Not really a problem and >I think it may be reasons to have one cache db anyway, so this is >just more of an observation. > * _get/_set/_delete interfaces are needed for cache metadata (last modified, >etc). Am working on it atm. > * if folder metadata is going to be free-form, it could be better to have >a key->value table ( folder_id_id int, key_name text, value text ) rather >than arbitrarily numbered text/binary fields. I was thinking of allowing the backends to store key value pairs using a bdata column which could be populated with xml key-value data. Would be it be good idea ? > * not sure of this one: given there may be multithreaded access to the db, >do we need to provide any external "big locks" on reads/writes? maybe >the built in sqlite stuff is sufficient. > * not sure of this one: beyond the COMMIT statements, should there be >something to periodically sync the db beyond the backend "finalize" > method? afaik it would be taken care of sqlite vfs and commit should be enough. >Unsure with commit is sufficient to get consistant on-disk in case of >crash, etc. > * do we need a set_populated/is_populated equivalent? or maybe that could >be solved in the cases it's needed wtih metadata. I think I added it and removed later thinking it might be redundant with sync_data column, but re-thinking now am clear both are independent. Will get that added... > * do we need a set_time/get_time equivalent? or maybe that could >be solved in the cases it's needed wtih metadata. There is a sync_data column which can be used for the same with either last_modified date or sequence numbers or some synchronization text. > > @chen: I don't know how active you plan to be on this, but if you're looking > to offload any work, I can pick up anything that results from the above if > you like. Just let me know! The work is almost over, but will let you know once i finish the testing and you can directly make changes if you require anything more there :) - Chenthill. > > > Sean > ___ 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 Thu, 2011-04-21 at 08:32 +0200, Milan Crha wrote: > On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote: > > On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: > > > I would like you to a incorporate some change to the free/busy api. > > > Some servers allow querying free/busy information > > > for multiple users at a time and the results appear in a iterative > > > fashion. The freebusy information of some > > > users are delivered first, while the server keeps fetching other > > > user's free/busy information. So if we could have he > > > FreeBusy api such as this, we could leverage those features, > > > > > > ECalClientFreeBusy > > > e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t > > > start, time_t end, const GSList *users, GCancellable *cancellable, > > > GError **error); > > > (with a async counter-part) > > > > > > Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar > > > *user, GSList *ecalcomps) > > > > > > The clients could watch for the signal and update the freebusy > > > information as and when they receive from eds. > > Hi, > I rethought my thoughts about this and I think I follow your idea more > closely now. If I try to rephrase it, then it might be: > > On the server side, add new >e_data_cal_notify_free_busy_data (..., const GSList *ecalcomps); > which invokes a signal on the D-Bus connection about (partial) result > for a free/busy request (note it doesn't provide user separately). > This signal will be valid only while a get_free_busy request is running. > Calling e_data_cal_notify_free_busy_data() out of these functions will > not fail, but the ECalClient consumer may not expect that being done. > With this limitation we'll have a possibility to cancel pending request, > if needed. The e_data_cal_respond_get_free_busy() will have no return > values. We could term it start_free_busy.. > > On the client side, the 'finish' function will be also void and any > information about free-busy will be available exclusively in a > "free-busy-received" signal, which will have a parameter GSList > *ecalcomps. Once a free_busy_done signal is received, the finish function can be called. Yup and on the whole I agree to what you have mentioned here. Thanks, Chenthill. > > I hope we are on the same line now. If you agree, then I'll make a > change in this way. > Thanks and bye, > Milan > > ___ > 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 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 Evolution-EWS to GNOME infrastructure.
On Thu, Apr 21, 2011 at 9:24 PM, David Woodhouse wrote: > On Thu, 2011-04-21 at 17:36 +0200, Milan Crha wrote: >> I understood that Chen wants this as a part of evolution-collab, where, >> as I understood it, will be added also evolution-exchange, >> evolution-mapi, groupwise bits, and one day, maybe also evolution-kolab. >> It may save you from bugzilla and new module procedure work, as Chen >> will do this all for you for free. > > Ah, are we still actually going ahead with that plan? I know it's been > discussed for some time... I have the tarballs ready with me. Will get them into git.gnome.org repo. by next week and you can import ews code also by the same time.. Thanks, Chenthill. > > -- > David Woodhouse Open Source Technology Centre > david.woodho...@intel.com Intel Corporation > > ___ > 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 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 Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes wrote: > On Mon, 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. > > Thanks for posting this, Milan. I want to emphasize how important these > new APIs are and ask everyone to look it over and provide comments. > > I had a sneak peek at this over the weekend and jotted some notes. So > far I've only reviewed in detail the client-side headers because that's > what I'm most concerned about getting right. The rest of it can be > tweaked and changed as needed -- even the backend APIs are never truly > frozen. But the client-side APIs *will* be frozen, since that's what > other projects will be migrating to and attempting to use. > > The new client-side APIs are: > > EClient (abstract base class) > http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-client.h?h=eclient > > ECalClient (replaces ECal) > http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal-client.h?h=eclient I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a iterative fashion. The freebusy information of some users are delivered first, while the server keeps fetching other user's free/busy information. So if we could have he FreeBusy api such as this, we could leverage those features, ECalClientFreeBusy e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t start, time_t end, const GSList *users, GCancellable *cancellable, GError **error); (with a async counter-part) Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar *user, GSList *ecalcomps) The clients could watch for the signal and update the freebusy information as and when they receive from eds. - Chenthill. > > EBookClient (replaces EBook) > http://git.gnome.org/browse/evolution-data-server/tree/addressbook/libebook/e-book-client.h?h=eclient > > ECredentials (authenication) > http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-credentials.h?h=eclient > > > I'll split my comments into two posts so this doesn't get too > overwhelming. Simple, hopefully non-controversial stuff here and > meatier topics in a separate post. Overall I'm pretty happy with > the APIs. > > > * There's some overlap between the new EClient API and the new > ESource API that I'm working on. Some functions will need to be > dropped once the new ESource API is in place, so I don't know if > you want to do this now or wait. > > ESourceList is being removed so obviously any functions involving > ESourceList will be dropped: > > e_client_util_get_system_source() > e_client_util_set_default() > e_client_util_get_source_for_uri() > e_cal_client_get_sources() > e_book_client_get_sources() > > We will no longer refer ESources using URIs. We will only refer > to ESources by their unique ID string. So the following functions > will be dropped: > > e_client_get_uri() > e_cal_client_new_from_uri() > e_book_client_new_from_uri() > > Default sources will be tracked using the new ESourceRegistry API, > so the following functions will be dropped: > > e_cal_client_set_default() > e_cal_client_set_default_source() > e_book_client_set_default() > e_book_client_set_default_source() > > There's a few functions that I think are too trivial to keep in light > of the lookup capabilities of ESourceRegistry. I'd like to keep the > EClient APIs as slim as possible initially and drop these functions: > > e_cal_client_new_system() > > Instead do: > > source = e_source_registry_lookup_by_uid (registry, "system"); > client = e_cal_client_new (source, source_type, error); > > 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); > > (similar functions exist for tasks and memos) > > e_book_client_new_system_addressbook() > > Instead do: > > source = e_source_registry_lookup_by_uid (registry, "system"); > client = e_book_client_new (source, error); > > e_book_client_new_default_addressbook() > > Instead do: > > source = e_source_registry_get_default_address_book (registry); > client = e_book_client_new (source, error);
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - April 20 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Check out http://live.gnome.org/Evolution/CommunityMeet for more details. - Chenthill. ___ 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] EWS MessageInfo leak wtf
On Sat, Apr 9, 2011 at 4:08 AM, David Woodhouse wrote: > ==5510== 41 bytes in 1 blocks are possibly lost in loss record 8,473 of 17,762 > ==5510== at 0x4A05E46: malloc (vg_replace_malloc.c:195) > ==5510== by 0x3B6A048B52: g_malloc (gmem.c:164) > ==5510== by 0x3B6A06101D: g_strdup (gstrfuncs.c:102) > ==5510== by 0x1693D7B1: ews_message_info_clone (camel-ews-summary.c:75) > ==5510== by 0x1693E4FD: camel_ews_summary_add_message_info > (camel-ews-summary.c:417) > ==5510== by 0x16940ADD: camel_ews_utils_sync_created_items > (camel-ews-utils.c:973) > ==5510== by 0x16939819: sync_created_items (camel-ews-folder.c:660) > ==5510== by 0x16939B41: ews_refresh_info_sync (camel-ews-folder.c:750) > ==5510== by 0x4C78C99: camel_folder_refresh_info (camel-folder.c:1156) > ==5510== by 0x33B6E7F0F7: mail_msg_proxy (mail-mt.c:469) > ==5510== by 0x3B6A06BBC3: g_thread_pool_thread_proxy (gthreadpool.c:319) > ==5510== by 0x3B6A069445: g_thread_create_proxy (gthread.c:1897) > ==5510== > > Can't repeat it; don't know how it happened... except of course that it > obviously happened when SyncFolderItems returned some created items. > > The frame in ews_message_info_clone() at camel_ews_summary:75 is setting > mi->change_key on the newly cloned MessageInfo: > http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l75 > > (I'm also *sure* it happened after commit 17bd5273 in which I fixed a > consistent leak of our mi->change_key by adding a message_info_free() > method to our class. Not only do I remember it that way, but the > timestamp of my valgrind log file is about four hours later than that > commit, and the *other* valgrind warnings that the ->change_key leak > caused are noticeable in their absence.) > > I'm confused by the use of camel_message_info_clone() in the first line > of camel_ews_summary_add_message_info(): > http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l417 > There is *one* caller of this function, and it's the one in the above > backtrace — camel_ews_utils_sync_create_items(): > http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-utils.c#l973 > > And that *creates* a new MessageInfo of its own... which AFAICT never > gets freed, although valgrind doesn't seem to be complaining about that, > and I don't know why. > > Removing the clone in camel_ews_summary_add_message_info() and just > using '(void *)info' seems to work just as well; I'm not really sure > what's going on here. And either way, I've never been able to repeat the > above warning. > > Chen, was there a reason for the clone? And why isn't valgrind > complaining about it? Can anyone see something that would cause the > above complaint that it *did* make? The ews_summary_clone seems un-necessary there. I picked up some code from the imapx provider and certainly did a mistake there. The const identifier for the CamelMessageInfo in the signature of the function and message_info_clone can be removed. - Chenthill. > > -- > dwmw2 > > ___ 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] Maintenance fork for Evolution / EDS 2.32
On Mon, Apr 4, 2011 at 12:23 PM, Milan Crha wrote: > On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: >> That's great; thanks. I'll do a little more testing on the patches >> I've cherry-picked into my trees, and then unless someone else has >> objected in the meantime I'll push them. > > Hi, > I objected against this many times, directly to you, on IRC, with no > effect, obviously. If I recall correctly, the reason why release-team > decreased releases is that distributions were *not* using .2 release. > Which is just the opposite you are trying to convince us. If they are > not using official releases, why should they use unofficial branch? > > By the way, how would you look for a fix user reported to your > distribution, as a distribution maintainer? The work-flow, as I > understand it, is like this: > a) user enters a bug report in your distro bugzilla > b) maintainer gathers enough information to identify the issue > c) check upstream bugzilla for a "duplicate" or possible fix > d) decide on the change whether backport or indicate "will be fixed > in the next stable/unstable release" > > Note that I do not expect anyone looking into git branch for a > particular fix, with a very good reason, they would rather check in > bugzilla, which offers much better searching ability and contains enough > information for possible bug matching, with compare of git commit. And > the bugzilla should have enough information about the fix, like either a > patch or a link to particular commit. The evolution-related products use > to it that way. This would certainly help distributions which want to stay with Evolution 2.32 for a while.. My only concern here is, while cherry-picking patches how would we take care of the translations and documentation ? Are we adhering to the freezes in the gnome-2-32 branch (am not calling this a latest stable branch) ? If the documentation and translations are taken care of, should the freezes matter ? - Chenthill. > > That's my opinion. > Bye, > Milan > > P.S.: as of today (or tomorrow, if you wish), the official stable > release is 3.0.0. > > ___ > 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 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 Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly wrote: > On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: >> On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly 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. But as I do not understand the use case, the suggestion may not even be relevant.. > > 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. - Chenthill. > >> Thick clients like evolution can still use the existing apis to avoid >> much changes unless there is a significant improvement >> in performance.. Maybe good to have some profiling data as well ? > > I have asked my colleagues working on the contacts app in MeeGo about > use cases they care 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] EDS improvements for MeeGo
On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly 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'. Thick clients like evolution can still use the existing apis to avoid much changes unless there is a significant improvement in performance.. Maybe good to have some profiling data as well ? - Chenthill. > > 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 > ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Mar 23 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Check out http://live.gnome.org/Evolution/CommunityMeet for more details. - Chenthill. ___ 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] Branch date?
On Tue, Mar 15, 2011 at 3:07 AM, Matthew Barnes wrote: > It's getting to be branching time again. I think in the past we've > usually branched when the hard code freeze starts, which would be next > Monday. Shall we go with that again or does anyone have a desire to > branch sooner? Am fine with branching on Monday after the hard-code freeze.. - Chenthill. > > (Speaking for myself, I don't really have anything ready to land yet.) > > ___ > 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 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] Sqlite cache for address-book storage in EDS
On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams wrote: > On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: >> On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes wrote: >> > Okay, this might be a long shot but I'm gonna throw it out there anyway: >> > would it make sense to look at using Xapian to index a directory of raw >> > vCards? >> Am not sure if its worth doing this for adress-book. Am just making an >> assumption that the >> address-book content may not be as huge as mail data. The only address-book >> data >> that would be large enough would be GAL (exchange) and >> SystemAdressBook (groupwise). > > This is a self-fulfilling prophecy; I and others have tried to have > large address books... which doesn't work... so address books remain > "small". I agree, the *only* should be removed from the third sentence of mine, there could be other address-books. While thinking of Xapian for address-book, am not still convinced. One could search on various fields such as sender, subject, recipients, full-text search etc. in mailer often and xapian is said to work much better. Although I have not got any profiling information as such, but its just from hearing from multiple people. But for address-books, the most often used searches would be based on name and email. Even if the address-book has 21k or more data, a db with good indexing should perform better. The information stored will be small when compared to mail content.. Well these are just my observations, are there any other cases am missing ? > > I have a CardDAV/GroupDAV collection of ~21,000 contacts I'd love to > have access to via Evolutions WebDAV address book. But anything more > than a thousand or so gets to be unbearably slow. AFAIR, there are some UI issues involved here which should be dealt with separately. - Chenthill. > > ___ > 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 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] Sqlite cache for address-book storage in EDS
On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes wrote: > > On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote: > > do not forget that the DB cache is compiled conditionally, because some > > distros do not ship libdb. Using SQLite for this was mentioned months > > ago, only no-one got time to actually do it, so go for it. > > Also, as far as I know there is still licensing issues between Berkeley > DB's Sleepcat license and [L]GPL, which is how libebackend was born. > > https://bugzilla.gnome.org/show_bug.cgi?id=465374 > > I'm +1 on dumping Berkeley DB. > > > > Only think of two things: > > - using binary storage for this kind of data is bad for cases where > > the binary file breaks, either due to an update/downgrade of the > > library providing access to it, or just by a crash. It's not so hot > > with camel as SQLite has there only summary data, but if you want to > > store also real data in it, then it can be a problem. There are people > > having issues recovering their data from addressbook storage already, > > but if you are going to do any change on it, then it would be good to > > think of that from the beginning. It would be good to store raw vCards > > in some plain text file(s) which will be "indexed" by SQLite summary. > > This plain text file(s) will be then easy to import to evolution if > > something goes wrong, and with erasing SQLite file user will not > > loose any valuable data. (I'm thinking of a flat maildir approach > > here.) > > Milan raises a good point about binary formats versus text. Would be > good for the raw data to remain human readable. Yes, it makes senses to store it that way. If we can index the data in sqlite summary and store VCards in the way we store individual mail data, it should be sufficient.. > > Okay, this might be a long shot but I'm gonna throw it out there anyway: > would it make sense to look at using Xapian to index a directory of raw > vCards? Am not sure if its worth doing this for adress-book. Am just making an assumption that the address-book content may not be as huge as mail data. The only address-book data that would be large enough would be GAL (exchange) and SystemAdressBook (groupwise). I think sqlite should suffice in indexing this.. > > We've been talking about moving to "notmuch" [1] for mail indexing, and > "notmuch" is built on Xapian. Trying out Xapian for address books might > be a good test drive for using it with mail. To be honest, I wont be having that much time for testing this for address-book. Jony was trying to evaluate the performance between sqlite and notmuch mail indexing for mails, any updates there Jony ? - Chenthill. > > The catch is, Xapian is written in C++. So we'd likely have to hand > write our own GObject bindings for it in C. That's what makes it a long > shot. But we could look to "notmuch" even WebKit/GTK+ for examples of > binding C++ to C. My C++ is rusty but I still have my Stroustrup text > book. > > > [1] http://notmuchmail.org/ > > ___ > 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Sqlite cache for address-book storage in EDS
Hi, I was going through the Address-book cache used in EDS while starting to write the address-book backend for EWS. We use EBookBackendCache that stores in the form of xml, EBookBackendDBCache which uses libdb for storing the VCard strings. While EBookBackendSummary stores the information about names, email ids for faster lookup. Some backends use EBookBackendCache and some use EBookBackendDBCache. ldap, google, webdave uses EBookBackendCache. file, groupwise, exchange uses EBookBackendDBCache. I was wondering if its worth writing a EBookBackendSqliteCache as we are already using sqlite for string emails and later migrating all backends to use the same. The summary and VCard strings can be stored in a single Cache without the need for using EBookBackendSummary. Any thoughts ? - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Feb 16 - 3:30 PM UTC
On Mon, Feb 14, 2011 at 10:51 PM, Matthew Barnes wrote: > On Mon, 2011-02-14 at 21:18 +0530, vikas ruhil wrote: > > > can tell in more detail about Meeting ? > > > i want to participate in meeting ? > > > so please tell ? > > See: http://projects.gnome.org/evolution/meetings.shtml > > We should add some boilerplate text to these meeting announcements that > includes the above link to the meeting log archives. > Will put in a detailed information in the wiki and add it to the meeting announcements. > > By the way, Chen, I won't be able to attend this week. If you or Milan > could send me the log I'll get it posted. > Sure, will send you. - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Feb 16 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ 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] (no subject)
On Wed, Feb 9, 2011 at 7:40 PM, thilagaraj thilak wrote: > sir, > i'm really interested in studiying linux, but i experienced in > windows environment. > sir,please tell me first of all what can i do for got experienced in > Linux environment with basics. > sir,unfortunately i joined evolution-hackers in gnome.org.but i can't > understand what they do and their purposes?, > i'm doing B.E(cse) fulltime 3rd year.my long day dream in my life > is to play in linux like windows environment.please please help me to > achieve my dream as well as my goal. > This is not a right forum to ask about contributing to linux and understanding linux. Anyways you can find a lot of sources by just googling. Checkout, http://live.gnome.org/JoinGnome http://en.wikipedia.org/wiki/Linux http://www.linuxforums.org/ I would encourage you to look listinfo and its archives to understand what a particular mailing-list is meant for before proceeding with your queries. - Chenthill. > > > Thank you sir!... > ___ > 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 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 documentation
On Mon, 2010-02-01 at 11:41 -0500, Shreyas Phadnis wrote: > On Mon, Feb 1, 2010 at 1:35 AM, chen wrote: > There is no documentation for imapx yet. You can refer to the > documentation for camel in www.go-evolution.org it is up to > date as of > now. Also feel free to clarify your doubts on irc #evolution > channel. > > > > > Thanks. I will refer to this documentation > > Would you be interested in putting some documentation for imapx while > u > learn the arch. where I could provide some help ? :) > > > > Yes, definitely. Why not? I will ping you IRC as I learn more. That would be great!! > > > BTW, IMAPX looks very promising. Its much snappier. Of course there > are occasional crashes (which I have not been able to reproduce > reliably). I am looking into enabling all the debug settings as I > explore more.. Have pushed in some fixes. Let me know if they fix the issues. Please send me the gdb traces or feel free to file a bug in bugzilla.gnome.org. Thanks, Chenthill. > > > ___ 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 09:56 -0500, Jeffrey Stedfast wrote: > On 12/15/2009 02:46 PM, Chenthill wrote: > > Hi fellow hackers!! > > I have been working for a while during last week on one the blockers > > in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 - > > 'Folder and summary mismatch error'(old one - > > https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact > > we have been working as a team to get the blockers down. I have not been > > able to reproduce the issue or yet find the exact problematic area. > > > > The mismatch in the frompos index in the folder summary may be caused > > by either a threading issue or a crash while storing the indexes. I am > > still investigating it to find the real cause. > > > > I don't think it's a threading or crash issue. Looking through the comments from both the bugs and the fixes that have gone through, i had this thought. Any other clues ? Thinking about the amount of time this bug has been there for (primarily with our mbox implementation) , I thought of making some change which could benefit more rather than trying to just fix this. This might not be an ideal way to think though :) - Chenthill. > > > Looking at other issues such as, > > https://bugzilla.gnome.org/show_bug.cgi?id=522433 - 'Fails opening mbox > > > >> 2GB', just got a thought if we could solve both the issues by, > >> > > > > This just means the proper LARGEFILE flags are not being used at compile > time. Either EDS's configure isn't doing proper checks or else Evolution > itself isn't doing proper checks and there is some sort of clash. > > An easy way to fix this is to do what I did with GMime, which is to > simply make all public stream APIs that use off_t use goffset instead > (I'm sure Matthew will want to do this anyway). Then the problem is much > simpler to solve - just make sure that Camel uses the proper CFLAGS for > LARGEFILE support (which you can steal from GMime's configure scripts). > > > Approach #1, > > migrating local storage from mbox to maildir format. With maildir I have > > heard about two issues, > > > > * Not able to create subfolders under INBOX - > > https://bugzilla.gnome.org/show_bug.cgi?id=536240 . > > > > This is just a bug and it should be fixed regardless. > > > Approach #2, > > Migrate from a single mbox file per folder to mbox per email. Srini > > mentioned an advantage that this would avoid the file renames that > > maildir does. I think this is much like how other remote providers in > > evo store the email. > > > > I'm not sure if you mean the CamelImapMessageCache way or CamelDataCache > (as someone else mentioned in this thread). > > Either way, it seems a messy way of organizing messages as well as > costly in terms of inodes (and possibly in wasted disk space, although > Meeks' email seems to suggest file-per-message might not be that bad). > Then there's the problem of getting mail into and out of this storage > scheme. (Note: Maildir would be less inode-intensive) > > I think that Evolution should always choose to use a standard mailbox > format rather than make up its own. So if the consensus is to move away > from mbox, then my vote would be with Maildir. > > We originally chose mbox (when I say originally, I mean for 2.x), it was > largely done because most other popular clients also sued mbox. One of > the things we had to do was to figure out a way to structure an mbox > folder tree, and the way I did that was to mimic Thunderbird's folder > layout (which was quite nice). IMHO, this was an added bonus because I > think that Thunderbird was the most likely candidate for people to be > switching to/from as it was the other major mail client at the time - > making migration as simple as a cp -r (or an mv) is pretty slick. > > Performance gotchas with Maildir: > > There were some comments earlier in this thread about not wanting to use > Maildir because of performance problems with rename(). It's not the > rename() which is the performance problem, but rather the fact that once > a message file is renamed, the client must scan the directory listing(s) > looking for the new name (strcmp()ing everything up to the ':' iirc). If > the volume of mail gets large enough, this could potentially be > problematic. I believe it was problematic on ext2, but things may have > changed since then. I should point out that this is ONLY a problem if > other clients are involved because Evo could (should) keep track of the > name changes in its summary files. > > Hope this helps, > > Jeff ___ 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 Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote: > On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote: > > > > > Approach #1, > > migrating local storage from mbox to maildir format. With maildir I > > have > > heard about two issues, > > > > * 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. > > > > Approach #2, > > Migrate from a single mbox file per folder to mbox per email. Srini > > mentioned an advantage that this would avoid the file renames that > > maildir does. I think this is much like how other remote providers > in > > evo store the email. > You still have a filename per email right? yes. > What naming convention would be used? We would be using the uid of the message . uid would be a 32 bit unsigned integer. > > > > I thought of bring this in this list to gather more opinions to > choose > > the right one. The approach #2 seems a better one as we are choosing > a > > way for storing the messages internally in evo. Are we missing to > see > > anything while we choose the second one ? > > > > One advantage which I see with #1 is that its a standard way. > Would Evo provide a mechanism to migrate/convert a mailbox/folder with > this format to a mailbox/folder with a standard format? Yes we would provide an UI option for exporting data. While going with the second approach, I would prefer exporting in maildir format. > I.E. Currently, dragging a folder in one format to an account in a > different format performs the proper migration to the new account's > folder format. > > Or would it be up to the user to do something like > > for file in `ls *mbox` > do >movemail $file maildir:///tmp/maildr > done > > if they wanted to migrate to standard format? It would be the same behavior as before with the mbox-file-per-email if we choose to do that. - Chenthill. > > > > Thanks, Chenthill. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Moving from the single mbox file format for the local folders
Hi fellow hackers!! I have been working for a while during last week on one the blockers in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 - 'Folder and summary mismatch error'(old one - https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact we have been working as a team to get the blockers down. I have not been able to reproduce the issue or yet find the exact problematic area. The mismatch in the frompos index in the folder summary may be caused by either a threading issue or a crash while storing the indexes. I am still investigating it to find the real cause. Looking at other issues such as, https://bugzilla.gnome.org/show_bug.cgi?id=522433 - 'Fails opening mbox > 2GB', just got a thought if we could solve both the issues by, Approach #1, migrating local storage from mbox to maildir format. With maildir I have heard about two issues, * Not able to create subfolders under INBOX - https://bugzilla.gnome.org/show_bug.cgi?id=536240 . Approach #2, Migrate from a single mbox file per folder to mbox per email. Srini mentioned an advantage that this would avoid the file renames that maildir does. I think this is much like how other remote providers in evo store the email. I thought of bring this in this list to gather more opinions to choose the right one. The approach #2 seems a better one as we are choosing a way for storing the messages internally in evo. Are we missing to see anything while we choose the second one ? One advantage which I see with #1 is that its a standard way. Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Manifesto
ternally it makes use of offlineimap, smtp, GW-MUA for whatever mail > transport. So a good news, Travis Reitter (treitter), Jonathon Jongsma (jonner) have started the work on mailer-to-eds :-) > > > The sqlite backend stuff could also use some work. As far as I'm > aware, > > the tables are non-optimal. At one point I noticed that UIDs (the > > primary key in the table) were stored as strings - it would be > better to > > store them as uint32s (yes, I know the gw and exchange backends do > not > > use uint32s for UIDs) for performance reasons. It should be possible > for > > these backends to have a second table which mapped the canonical > uint32 > > UID key to the key used by the servers. > > > > Yes. when Srini and I started with the sqlite summary work, we planned > to implement the basic workflow first and then to improve the database > in more effective ways. But sadly none of us work anymore on > Evolution directly and we weren't aware of these surprises when we > implemented the initial version of sqlite summary. > > One important area that could improve immensely is Search. We now do a > "Like ''" query on database often leading to slowed search > results. We can create more indices and once the user starts typing in > the text box, we can autocomplete adn do a EXACT Search in teh > database often leading to faster results. For instance, if I search > for Fejj now the query that goes to db is LIKE FEJJ. Whereas, if we > can autocomplete during the search and show f...@novell.com, then in > the database it is faster to search with a EXACT match. this may not > look like a big improvement in theory but I believe it will be a big > usability improvement and can also of be use for other applications > that will rely on us, when camel becomes a service etc. Sadly, I was > never able to make the management understand the need for this when I > was in the team and also we never had the time to complete the > disk-summary migration and other related tasks etc. > > > Additionally, the way Camel current works (even now, with the sqlite > > backend), when a folder is opened, the entire summary for the folder > is > > loaded the same as it used to be before the sqlite changes. This > seems > > rather... wasteful? Kinda defeats the purpose of using sqlite (or > any > > other database backend). The main problem with the older format is > that > > it did not allow random-access, which means we really needed to load > the > > whole thing into memory for a number of reasons: > > > >1. each record being a different size requires sequential > access > > from disk > >2. can't sort by sender, subject, date (or whatever) until you > have > > the entire summary in memory > >3. doing lookups on message UIDs would be prohibitively slow > from disk > > > > With a db backend, none of these problems exist any longer. Some > Camel > > APIs would likely need to change in order to support taking > advantage of > > this new feature, but it's something that needs to be done. > > > > IIRC, For showing in message list, we already fetch only whatever > records are needed and do not load the full summary onto the memory. > For instance, if you have selected "Unread mail" in the QuickShow > combo box, only unread mails' summary items are loaded. > > > > > These things seem like much bigger wins for Camel's (and, by > extension, > > Evolution's) usability/maintainability than making Camel async and > are > > also far more trivial to implement. > > > > Just some things to think about... > > > > I tend to agree with Fejj on this and I am big fan of threads. But I > no longer work on evo and knowing Matthew I believe he knows what is > the best. All the best :-) We are all part of evolution community :) So would be good not to say, "am not longer working on evo". Sharing opinions/ideas is a big contribution in it-self :) It helps people who contribute through code to do the right things. just a humble thought. - Chenthill. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Agenda for the community meeting - Thursday (3:30 PM UTC - 4:30 PM UTC)
Hi all, We would be discussing on the following items, * go through the blockers * pending patch reviews * status updates Bugs from Akhil listed last week - https://bugzilla.gnome.org/show_bug.cgi?id=593700 [regression] Opens folder on top https://bugzilla.gnome.org/show_bug.cgi?id=597648 evolution crashed : moved to calendar https://bugzilla.gnome.org/show_bug.cgi?id=601519 Cannot start evolution-alarm-notify process https://bugzilla.gnome.org/show_bug.cgi?id=601525 e-calendar-factory crashes the second time I start evo https://bugzilla.gnome.org/show_bug.cgi?id=596566 gtkhtml crash https://bugzilla.gnome.org/show_bug.cgi?id=555262 evolution and pidgin hangs https://bugzilla.gnome.org/show_bug.cgi?id=598769 (MAPI) evolution-data-server-2.28 crashed with SIGSEGV in find_SPropValue_data() https://bugzilla.gnome.org/show_bug.cgi?id=585615 (MAPI) Exchange MAPI account setup gets wrong userid in database https://bugzilla.gnome.org/show_bug.cgi?id=601484 (MAPI) cann't accept a meeting request https://bugzilla.gnome.org/show_bug.cgi?id=600560 - MAPI Potential blocker Calendar information only up to yesterday https://bugzilla.gnome.org/show_bug.cgi?id=601202 (MAPI) Evo will delete your addressbook on the server with no warning This list will be debated and improved moving further. Pitch inside #evolution-meet (irc.gimpnet.org) irc channel to discuss and share thoughts with the developers!! Attached the last weeks meeting logs. - Chenthill. Lets get started in another minute and have a small discussion to know whats happening and moving further with coming releases "releases", hmm mcrha, yup we have 2.28.1 and 29.1 coming this month * mcrha was hoping in the upcoming year forecast :) ;) lol step by step as we all know dbus calendar has been merged now yeah, one big step, then few small steps and i would like lakhil to play a major part in bringing the major bugs during every meeting and we can share the bugs among us assigning and making sure the issues are fixed before the release chen, i keep sharing in irc daily ... though i will try to prepare one for meeting * mcrha noticed flood of those yesterday prolly we can discuss over bugs like https://bugzilla.gnome.org/show_bug.cgi?id=557613 to ensure they are fixed on time lakhil, bring it to light and discussing it would make sure these go in before the release yeah, sure lakhil, would be great if you have a list before us during these meetings :) mcrha, and coming on patch reviews, know there are lot of ur patches waiting on the same actually, i changes a strategy slightly mcrha, can all the patches which are straight forward or if your confident on the fixes be committed directly ? and consult on the fixes where you have some doubt.. I attach patches for "test or review", if reporter can try the patch and says ok, then I commit chen, yup, i can do that, I was hoping in starting with that on January, though mcrha, oh why ? mcrha, prolly you can attach the patch marking it as committed right away just for fun of attaching patches to bugzilla. does it worth it? mcrha, and the left ones means that they are requiring some review comment mcrha, don think so 'don' ~~ don't? ok don't :) just clarifying a meaning. I do not think it worth it too, the commit ID should be enough there mcrha, i would say testing from the reporter is fine, but commit it if you feel the approach taken is correct mcrha, agree you know the code will be quite different when you allow me to commit without asking, right? mcrha, well we have all spent enough time to make a judgement whether the approach is right or wrong and of-course having a review is always better, but considering the ammount of people we have now we will not be able to follow the same style right, that's a bad thing (low human resources) mcrha, so if you have patches, which are on the above category commit them! i mean for the patches right now in the bugzilla as well * mcrha is wondering how chen means 'if' :) :D :D * chen leaves the rest to mcrha :) patches in bugzilla, I miss the user statistic page there mcrha, now it's added back haha and lakhil the points page :D lol all are back :D chen, I'll go the safe side, killing master only aah :D mcrha: lol lakhil, is the statistics page back? you the one who has to save the killing :D mcrha, ok, hold it on stable as well by ur judgement mcrha, yep lakhil, good, let me look how I stand for past few weeks ;) to update what i have been doing, chen, yeah, stable is a different story https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html committed the imapx initial stuff to master and cooked a patch for ebook issue perhaps feel it has to be combined with mcrha's patch on keeping open ebook's in memory mcrha, i felt that the open ebooks can be kept i
[Evolution-hackers] evolution 2.28.0 released!!
Hi all, Evolution team is happy and proud to announce the evolution 2.28.0 release. To give an overview of what the release provides, • Google calendar will be available through Caldav interface by default • Support for unmatched vfolder and creating vfolder using vfolders is added back. • Configurable date formats • Selecting local ICal files as calendar sources • Better Calendar cache • Attachment bar rewrite • GroupWise conversation threading • GroupWise meeting retract/resend • Tons of bug fixes As many would know already, we branched evolution early in order to get rid of bonobo. Am happy to see this from mbarnes! We have already started working on the tasks identified for the 2.30. Here is the summary of those tasks, • Bonobo less Evolution • EDS DBus port • Exchange MAPI Improvements • Mailer async operations (with IMAPX) • GNOME 3.0 Cleanup • Migrate go-evolution wiki contents to lgo and gnome.org/projects/evolution • Quick steps for writing evolution plugins • Disk summary regressions on vfolder If you would like to get involved in any of the above mentioned work or have some new ideas, we would be happy to guide. We need more people getting involved in Evolution development! This is a special release for myself and mbarnes as we have taken the responsibility of maintainer-ship from this release. Thanks to all the users, testers, developers, translators, bug masters, distributors and everyone involved in the project. Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution branched for GNOME 2.28
Hi, We have made a early branching for evolution for GNOME 2.28. We have been discussing on this in the past and to have the context, please go through the following threads, http://mail.gnome.org/archives/evolution-hackers/2009-August/msg8.html and http://mail.gnome.org/archives/release-team/2009-June/msg00018.html The following modules have been branched, gtkhtml, evolution-data-server, evolution and evolution-exchange. The branch is gnome-2-28. Only critical fixes will be made for evolution-2.28. By critical fixes, I mean blockers and important bugs identified as must-fix by module maintainers. All freezes would apply for gnome-2-28 branch. Please note that these patches needs to be committed to master and gnome-2-28 branch. The kill-bonobo-branch and eds-dbus-port will be merged into master. So it means master will not have any freezes. Most of the active work will be going on master branch to get it usable for evolution 2.29.1. Once the branches are merged to trunk, we would be replying back to this thread mentioning the same. We have made a rough road-map for Evolution 3.0 - http://www.go-evolution.org/Evo3.0 which will be discussed and modified further. We will also be discussing over some pending tasks from Evolution 2.28 and include the ones which are possible for http://www.go-evolution.org/Evo2.28 . Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Branching for Evolution 2.28 on Aug 11
Hi, We have been waiting for a while to get the eds address-book dbus port merged into master for 2.28. Considering the stability issues we have at the moment with the branch (http://tinyurl.com/bgo-eds-dbus-hybrid ) and some work which needs to be done for evolution-exchange to work, we will be merging into master immediately after the branching for 2.28. Kill-bonobo branch will also get merged and we will have enough time to work through them for 3.0. We would also be merging the eds calendar dbus port. Most of the work will be going on in master to get the ported pieces stable after branching. So when 2.29.1 comes out on oct 28 with these changes, we can assure some stability. Branching for 2.28 will be done on Aug 11th immediately after the UI freeze/2.27.90 release. I will send out another mail after branching so that developers ensure the relevant patches are committed to both 2.28 branch and master. Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
On Thu, 2009-07-30 at 07:25 -0400, Matthew Barnes wrote: > On Thu, 2009-07-30 at 11:32 +0530, Chenthill wrote: > > The archived contents would be eventually moved to > > www.gnome.org/projects/evolution . Time-line for the same is not yet > > decided. Until then the contents would remain in go-evolution.org. > > Okay, so what does moving wiki contents to a non-wiki website mean > exactly? Do we snapshot all the pages and copy the static HTML? And if > we do that, how do we find archived wiki pages without the wiki's search > feature? I guess we'd have to set up a global index page or something? Yes copying the static html. Manual work might be required. We should be having indexes like we have already at, http://projects.gnome.org/evolution/developer.shtml . > > Another option, perhaps only for the short-term, might be to just lock > down go-evolution.org so no new accounts, pages, or edits are possible. > That should preserve the search feature, and also solve the spam > problem, no? Possible. We still need get the admin right for that. Nirav ? > > On a different note, now that we've decided to move we need to compile a > list of which pages to move. How about we set up a wiki page for that > and invite both developers and the community (or at least the evo-list > subscribers) to add what wiki pages they'd like to see moved. Set a > deadline of, say, end of August? Lets first gather the contents to be migrated to lgo and gnome.org/projects/evolution. This will give us an idea to choose a right dead-line along with individuals for the tasks. > > On a third note, anyone know of a good MediaWiki-to-MoinMoin syntax > conversion program? My Google results have yielded mostly conversion > scripts in the opposite direction (MoinMoin-to-MediaWiki), or else > software that requires admin access to the MoinMoin database. I searched for it sometime back. I did find scripts to convert form moinmoin-to-mediawiki but not vice-versa :( May be a question on pgo might help to find if anyone else knows ? - Chenthill. > > Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
We had a discussion in yesterday's #evolution-meet about the go-evolution.org wiki to conclude on things. We have now made a decision to move the wiki to l.g.o. The archived contents would be eventually moved to www.gnome.org/projects/evolution . Time-line for the same is not yet decided. Until then the contents would remain in go-evolution.org. Meeting logs - http://projects.gnome.org/evolution/meeting-logs/2009-07-29.shtml . Thanks, Chenthill. On Mon, 2009-07-27 at 17:51 +, Matthew Barnes wrote: > On Mon, 2009-07-27 at 22:57 +0530, Johnny Jacob wrote: > > http://www.go-evolution.org/Special:Version > > > > Mediawiki :-) > > Ah, thanks for that! Now I can actually conduct some experiments. > > Matthew Barnes > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
We had a discussion in yesterday's #evolution-meet about the go-evolution.org wiki to conclude on things. We have now made a decision to move the wiki to l.g.o. The archived contents would be eventually moved to www.gnome.org/projects/evolution . Time-line for the same is not yet decided. Until then the contents would remain in go-evolution.org. Meeting logs - http://projects.gnome.org/evolution/meeting-logs/2009-07-29.shtml . Thanks, Chenthill. On Mon, 2009-07-27 at 17:51 +, Matthew Barnes wrote: > On Mon, 2009-07-27 at 22:57 +0530, Johnny Jacob wrote: > > http://www.go-evolution.org/Special:Version > > > > Mediawiki :-) > > Ah, thanks for that! Now I can actually conduct some experiments. > > Matthew Barnes > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ 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
On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote: > 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. Then changes made are reasonable. Nice api documentation! This can be done in calendar also. For calendars we use sequence numbers for items shared with people and last-modified in general. > > 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. Would be better to get these api's committed after the branching is done for 2.27.x. We will be merging the eds-addressbook dbus port this week (for 2.27.x) and the calendar part for evolution 3.0. Will keep you informed on the same. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
On Thu, 2009-07-23 at 11:09 -0400, Matthew Barnes wrote: > On Thu, 2009-07-23 at 06:15 -0600, P Chenthill wrote: > > We would still need to maintain the old data to know the history though > > they may become obsolete. Certainly a lot of things mentioned still hold > > true ;) > > A compromise might be to only migrate the pages with current and > accurate information to l.g.o, and keep go-evolution.org around as a > historical archive. Archived pages brought back to life at a later date > could be migrated individually. It -is- a wiki, after all. Makes sense. How about putting the architecture and other historic data on roadmaps into www.gnome.org/projects/evolution and current pages in l.g.o ? Close go-evolution.org once for all. - Chenthill. > > Might be interesting to compile a list of pages we still maintain or > care about. I have a few not listed on the front page (BugzillaTopics > and ReleaseHOWTO, for example). > > Perhaps a bigger issue is converting the page markup. I've noticed > syntactic differences between the two sites [1], but I don't even know > what wiki software the two sites are using. Need to see if there's > markup migration scripts out there. > > Matthew Barnes > > > [1] live.gnome.org's markup syntax seems way more expressive and is > actually DOCUMENTED! (http://live.gnome.org/HelpOnEditing) Unlike > our own. (http://www.go-evolution.org/Help:Editing) Not to mention > the style sheets are prettier. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
On Thu, 2009-07-23 at 07:34 -0400, Matthew Barnes wrote: > On Thu, 2009-07-23 at 14:35 +0530, Sankar P wrote: > > I don't see a high data content. There are Camel docs, plugin docs, > > some design docs about shell and threading, most of which will have to > > change anyway, soon. And most of the other links originating from the > > go-evolution home page points to obsolete contents. There are some > > test cases, but iirc they are stored in Novell testopia already. We would still need to maintain the old data to know the history though they may become obsolete. Certainly a lot of things mentioned still hold true ;) > <...snip...> > > > If all these does not convince you, you can save dollars on the > > storage space for the site ;-) . So imho, it is definitely worth > > moving to live.gnome.org . > > +1 Well stated. :) I concur with this provided all the old data are still maintained. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
Am including nirav in the thread. He is working on with the novell IS&T to get the required rights. He would be able to provide more details.. Thanks, Chenthill. On Mon, 2009-07-13 at 11:06 +0200, Andre Klapper wrote: > Am Sonntag, den 12.07.2009, 21:31 -0400 schrieb Matthew Barnes: > > I don't know how feasible this is, but what do you guys think about > > eventually migrating the wiki to live.gnome.org/evolution. > > I am all for it. > > > I have no idea who has admin rights to the wiki > > According to Parag Srini has sysop rights. > > andre ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Request for upgrading the minimum sqlite version to the latest stable version 3.6.x
Hi, I have been using sqlite-3.6.16 version for around 2 weeks and it seems to work fine. I have updated the external dependencies page for gnome 2.27.x with minimum and recommended version of sqlite to be 3.6.16. The jhbuild moduleset needs to be updated. There is a patch which modifies configure.ac and configure script to add some options. The patch for configure script needs to be regenerated for sqlite 3.6.16. Thanks, Chenthill. On Wed, 2009-06-03 at 04:43 -0600, Chenthill(P Chenthill) wrote: > To be more specific 3.6.x = 3.6.14.2 (latest stable version) would be > better unless there is a reason not to have it as a minimum version. > > Thanks, Chenthill. > On Wed, 2009-06-03 at 15:27 +0530, Chenthill wrote: > > Hi, > >We (evolution team) would like to request upgrading the minimum > > required version for sqlite to 3.6.x from 3.5.9 for the following > > reasons, > > > > 1) Api change in xCheckReservedLock method. (reference - > > http://bugzilla.gnome.org/show_bug.cgi?id=575084 ) > > 2) Most of the distributions have sqlite 3.6 > > > > Am adding ddl in CC to see if any other application has any issues with the > > same. > > > > Thanks, Chenthill. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
On Sun, 2009-07-12 at 21:31 -0400, Matthew Barnes wrote: > On Mon, 2009-07-13 at 00:24 +0200, Gilles Dartiguelongue wrote: > > Le mardi 24 février 2009 à 00:44 +0100, Andre Klapper a écrit : > > > Hej hej Parag! > > > > > > Some Novell folks told me that you maintain go-evolution.org which is > > > constantly spammed by bots, see Gilles' email here: > > > http://mail.gnome.org/archives/evolution-hackers/2009-February/msg5.html > > > > > > > > > For a quick solution, can you please remove the account "GetelNovia"? > > > > > > Any proposals for a long term solution, like updating the wiki software > > > (captchas etc)? > > > > > Any updates on this stuff, I'm now confronted with spambots which create > > random accounts and write spam to their user page. > > > > See: > > http://www.go-evolution.org/index.php?title=Special:Recentchanges&days=30&limit=500 > > > > I don't know how feasible this is, but what do you guys think about > eventually migrating the wiki to live.gnome.org/evolution. All the > pages could be rooted from there, e.g.: > > go-evolution.org/FAQ -> live.gnome.org/evolution/FAQ > > I have no idea who has admin rights to the wiki nor whether those > person(s) even maintain it anymore. I also have not been able to get a > straight answer out of anyone after asking repeatedly for admin rights. I heard from srini that he got the rights from parag but does not seem to see the admin page when he logs in. So not sure who has it exactly. > > I presume live.gnome.org is actively maintained with stronger anti-spam > measures, and I think it's a more suitable place for Evolution content. > Plus, it would be easier to link to other GNOME-related information on > that wiki. +1. Just one small concern, we have considerable amount of data in go-evolution.org, would it be good to have everything in live.gnome.org ? Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GNOME 3.0 - Evolution plans & IRC team meeting
I will not be able to attend the irc meeting today. But the following log has the discussion we had on Wednesday night in the channel. My opinions are put in there. It would be good if its taken into account while discussing this in the meeting. - Chenthill. On Tue, 2009-06-23 at 22:47 +0530, Srinivasa Ragavan wrote: > Guys, > > We have made some proposals to the release-team on GNOME 3.0 plans for > Evolution. Specially release/scheduling specifics. Read through the > thread. > > http://mail.gnome.org/archives/release-team/2009-June/msg00018.html > > We'll probably workout the exact schedule/decision. > > I wanted to discuss this in tomorrow irc team meeting. But due to my > busy schedule and tight meetings tomorrow, I won't be able to make it, > and I want to post-pone the team meeting to thursday (UTC 10:00) just > this time. Sorry, if this is a late notice. > > Try to make it or keep me informed if you have some > suggestions/thoughts. TIA. > > -Srini. > > > > > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers srag: hi srag: you 2.26 to be 2.28 and 2.27 to be unstable is a very not cool idea! your srag: it basically means "let's screw all those who track GNOME 2.27 and have already updated to 2.27.n" ! The final composer addressbook bug seems to be related to whether the data has finished loading when you press enter. * nxvl has quit (leaving) hey seb128 * cosimoc (~cosi...@jalfrezi.collabora.co.uk) has joined #evolution no... I can't reproduce... :( but do you think 2.28 will be stable with eds/dbus port and KB merging? or delaying that would stabilize 3.0 ? * nxvl (~n...@200.106.87.231) has joined #evolution * tbf__ has quit (Read error: 145 (Connection timed out)) * nxvl has quit (leaving) seb128, but do you think 2.28 will be stable with eds/dbus port and KB merging? or delaying that would stabilize 3.0 ? * You are now known as chen * nxvl (~n...@200.106.87.231) has joined #evolution if current 2.27.x is stable enough and does not contain dbus-port and kill-bonobo it should become 2.28. evo should branch very early (soon) for 2.29.x and get dbus and kill-bonobo in. but i think that's discussed by the evo team seb128, ^^ yes, i would like to see if we can get a window for three major things lined up for calendar along with older patches (which I have noted in my release machine), * tbf (~math...@dslb-088-067-108-091.pools.arcor-ip.net) has joined #evolution * cache rewrite - http://www.go-evolution.org/CalendarStore , Gsoc eds optimization patches and google calendar replaced by caldav at the backend so who maintains the addressbook and can finally review 556061? andre, chen but that leaves master out of testing for quite some time. my other worry is many good patches which inbolves more changes have not been taken into trunk. i just heard from mcrha early w.r.t caldav which we need to look at.. its as simple as merging late. srag, so if these are covered, i have no issues :) srag: well, distros are free to package master for testing chen, the patches ? kill-bonobo is available for fedora ubuntu can also package it er er? srag, i have noted some which break freezes, but really good to have. I have the list on another system in office. i can mail them across as a reply back to thread.. andre, but honestly, people won't use it, unless its the *official* version andre, yes, I guess we could. But it will be a PPA release, not a main chen, we can take up that.. not a problem. hggdh, sure andre, Im fine to have both 2.27.x and 2.26.x released till 3.0 comes out.. but have not covered the patches which have not committed in stable. i think all individual maintainers have to look at the patches on the components to just ensure.. srag, encourage people to do so srag, the issue is we already delivered 2.27.3 to Karmic, going back will be a pain there's blogs and mailing lists. hggdh, if its a matter of version, we can work that out.. cache shouldn't be a problem. hggdh, but I understand your issue that's why i currently also favor making 2.27.x -> 2.28.x and branch very early (and to be very conservative for 2.27.x for the rest of the time) andre, right, I love that proposal really, but Im afraid, it would miss the good amount of testing that can happen if its called 2.27.x :( andre, +1 srag, what is "it"? the master branch Im trying to recall something that happened with gdm, dont know the exact releases/numbers archlinux and debian still ship gdm 2.20 in their current unstable i don't think it's that similar though not similar, but would be great, if distros ship 2.27.x and together with 2.26.0 for stability reasons It could
Re: [Evolution-hackers] Evolution thoughts for GNOME 3.0
On Thu, 2009-06-18 at 02:21 +0200, Andre Klapper wrote: > Am Mittwoch, den 17.06.2009, 23:50 +0530 schrieb Srinivasa Ragavan: > > - Continue Evolution 2.26 as stable series till 3.0 comes out. > > - Treat Evolution 2.28 as a intermediate milestone for GNOME/Evolution > > 3.0 > > - Continue releasing Evolution 2.26.x (Evolution 2.26.5/6/7...) series > > as stable releases for GNOME 2.28.1/2/3 instead of releasing Evolution > > 2.28.1/2/3. > > You might call the stable Evolution releases "2.28.x" but create them > from the gnome-2-26 branch. On the other hand that is confusing if you > were up to continue calling the unstable series for 3.0 "2.27.x". > So we ship e.g. Evolution 2.26.6/.7 for GNOME 2.28.1/.2? > > > r-t: Having GNOME releases in mind I wonder which release suite an > Evolution 2.27.13 release would be part of in the last weeks of GNOME > 2.27.x - I don't think we should include a 2.27.13 Evolution release in > e.g. GNOME 2.27.92. People expect components of a release candidate (two > weeks before a major release) to be way more stable than Evolution > 2.27.13 at that time (6 months before a major release). > So how to ensure testing of the continued unstable branch in the last > weeks before 2.28.0? > r-t could think of an additional 2.29.0 release (shipping all modules > that have branched for gnome-3-0 already before 2.28 release) maybe one > week before 2.28.0? I somehow miss the last reply from Srini on this thread though I see it in web. So replying back to this. I like the idea of not branching and continue to port the code for killing bonobo from eds and evolution. But we also need to consider some patches which have added API and some string changes. There might not be many UI changes, but still there might be some useful ones. I don have the entire list now as we have not discussed/looked over them yet. I have not yet got the GSoc EDS optimization patches, but if I can get them over soon and if its good enough I would love to push them to stable branch along with calendar cache rewrite (http://www.go-evolution.org/Evo2.28) (quoting one case). Thinking about the freezes API/ABI/Feature freezes coming along in a months time. What about branching for gnome-2-27 immediately after that and starting to merge the kill bonobo stuffs ? This would mean we will not need to think about the merging important patches with freeze breaks into stable. So instead of 9 months we would have 8 months. - Chenthill. > > > I expect lot of rewrites, dbus port merge, bonobo deprecation (kill > > bonobo merge). etc. I don't think, Evolution 2.28 can be stable, unless > > I postpone these tasks which might merge late in 2.28 cycle to really > > 2.29.x. > [...] > > Thoughts on this? > > After some bad experiences with kill-summary bugs in 2.24.x I agree with > your proposal to continue 2.27.x for the next 9 months and kind of drop > 2.28.x. > > > Secondly, Evolution uses GNOME canvas in and around every UI. I wanted > > to know the future direction/migration path, haven't seen one before. > > Its gonna be another painful task like deprecating bonobo with in > > Evolution :/. I would like to vote against this, if there is a > > possibility. > > http://bugzilla.gnome.org/show_bug.cgi?id=571742 > > I still have not found out when and why libgnomecanvas was deprecated by > the release-team. Maybe someone remembers? > > According to http://www.gnome.org/~fpeters/299.html Evolution, planner > and gthumb use libgnomecanvas. > > andre ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Request for upgrading the minimum sqlite version to the latest stable version 3.6.x
To be more specific 3.6.x = 3.6.14.2 (latest stable version) would be better unless there is a reason not to have it as a minimum version. Thanks, Chenthill. On Wed, 2009-06-03 at 15:27 +0530, Chenthill wrote: > Hi, >We (evolution team) would like to request upgrading the minimum > required version for sqlite to 3.6.x from 3.5.9 for the following > reasons, > > 1) Api change in xCheckReservedLock method. (reference - > http://bugzilla.gnome.org/show_bug.cgi?id=575084 ) > 2) Most of the distributions have sqlite 3.6 > > Am adding ddl in CC to see if any other application has any issues with the > same. > > Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Request for upgrading the minimum sqlite version to the latest stable version 3.6.x
Hi, We (evolution team) would like to request upgrading the minimum required version for sqlite to 3.6.x from 3.5.9 for the following reasons, 1) Api change in xCheckReservedLock method. (reference - http://bugzilla.gnome.org/show_bug.cgi?id=575084 ) 2) Most of the distributions have sqlite 3.6 Am adding ddl in CC to see if any other application has any issues with the same. Thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Coding style
On Mon, 2009-06-01 at 16:13 +0100, Ross Burton wrote: > Hi, > > Whilst working on the merge of eds-dbus I noticed again that the coding > styles in e-d-s are really mixed up. What is the official coding style > (mainly indent size and tabs/spaces)? You find the official coding-style at http://projects.gnome.org/evolution/patch.shtml I should admit that we have not followed strictly. - Chenthill. > > Ross > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GSoc work on EDS optimization
Hi Slusny, It would be good if you attach the GSoc code into bugzilla or somewhere so that I can apply it on trunk and have a go with it. I found some code at http://github.com/slusnys/evolution-data-server/tree/master but not sure if it has the complete set of patches. If we can get things done a little faster, it can be targeted for evolution 2.27.2. -- thanks, chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libgdata
On Sun, 2009-02-22 at 22:44 +, Philip Withnall wrote: > Hi, > > I've been writing a full C library to access GData-based services, with > the aims of: > > 1. rewriting Totem's YouTube plugin in C, > 2. providing a useful desktop-wide way to access Google services, and > 3. merging it with the libgdata and libgdata-google in e-d-s' tree, such > that e-d-s depends on a proper, external library for its Google Calendar > server backend. > > I'm getting to the stage where it would be possible to merge with the > code in e-d-s' libgdata, but obviously this can only happen if the > authors of e-d-s' libgdata agree and think this is a good idea. If you > want to keep your libgdata separate and untouched, I'm happy to go along > with that, although it seems like a missed opportunity as regards > reducing code duplication across the desktop. > > The code is currently on Github[1], with the beginnings of Google > Calendar support in a branch[2], but the eventual aim is to move it to > GNOME SVN (or git, or whatever) and move it into the desktop platform. EDS provides data primarily for mail,contacts, calendar, memos and tasks. It would be good to move the libgdata code from EDS into a separate project, say 'gdata-c' in order provide entire set of Google services. You can probably create a new project in svn.gnome.org for the same. - Chenthill. > > Regards, > Philip Withnall > > [1]: http://github.com/pwithnall/libgdata/tree/master > [2]: http://github.com/pwithnall/libgdata/tree/calendar > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Status of the DBus port, future plans
On Tue, 2009-01-13 at 14:50 +, Ross Burton wrote: > Hi, > > As some of you may have noticed, there is a "dbus" branch in EDS now. > At present it contains a minimal port of the addressbook part of > eds-dbus to a fairly current (~1 week old) EDS tree. This mostly works > and after a little cleanup should be ready for more testing. However > there is a small problem with the calendar port which will take a bit of > explaining. > > First an overview of some technical details as background. The ORBit > addressbook and calendar have an "interesting" design which is as > follows. The client makes one-way method calls to the server, which as > the name implies do not respond. The server then makes one-way method > calls to a listener interface on the client, which then determines what > method call in the client this corresponds to. The addressbook has > integer operation ids to do this, whereas the calendar code doesn't > allow simultaneous calls because it has the notion of a "current" > operation. This isn't a great problem for the calendar, because the > only async method it has is open(). We have been doing a lot of workarounds to achieve async behavior for other api's in evolution. The dbus port would help in fixing them!! > > The thing is, this design has effected the design of libedata-cal. The > DBus port uses a cleaner design of method calls having return values, > which thanks to DBus and dbus-glib is trivial to implement on both the > client and server. The addressbook backends use the operation ID as a > entry into a hash table of DBus method contexts, but the calendar > backend API doesn't have anywhere to put the method context. > > I'll cut to the chase. This is an example of the current prototypes in > e-cal-backend.h, which is the interface backends (file, webcal, etc) > implement: > > void e_cal_backend_get_object > (ECalBackend *backend, EDataCal *cal, const char *uid, const char *rid); > > The current eds-dbus uses this: > > void e_cal_backend_get_object > (ECalBackend *backend, EDataCal *cal, DBusGMethodInvocation *context, > const char *uid, const char *rid); > > Note the addition of the DBus method context, so that the (potentially > much later) reply can be sent. I'm going to change it to something like > this: > > void e_cal_backend_get_object > (ECalBackend *backend, EDataCal *cal, EServerMethodContext *context, > const char *uid, const char *rid); > > Where EServerMethodContext is an opaque pointer, so the backends can't > do anything with it apart from pass it back to the server. Internally > it will remain a DBusGMethodInvocation*. > > > So, the gist of this rambling message is this: to merge the DBus port in > the current state I'd need to add a context argument to all of the > methods in e-cal-backend. This will break API and I'll obviously be > fixing the backends which are shipped as part of EDS at the same time. > The good news is that the e-cal-backend-sync helper class effectively > shields users of that from the change, so this affects less backends > than you'd expect. > > The alternative is to clone the ORBit API with DBus and use oneway > methods and the listener object. This is substantial pointless > complication and won't allow us to add missing async versions of the > entire ECal API in the future, so I'm voting against this. > > Any comments? Its better to change the API in this case. We can probably list down owners for the external backends like scalix and inform them about the change while getting it into trunk. I assume this is going to be in for GNOME 2.28, so we have enough time to inform them and to let them make changes. This is a welcome change and am completely for it!! thanks, Chenthill. > > Ross > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ 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
ed time. > > Exact handling of REV and LAST-MODIFIED in the two calls is basically > undefined right now as far as I can tell. I suggest to clarify that: > * backends should check them as described above > * backends must update them independently of what the client sends > > To allow clients to query whether the backend supports the check I > suggest to add a new capability for e_cal_get_static_capability() and > e_book_check_static_capabilities(). > > Any comments? With respect to the e_cal_remove* API, it would be good to have last modified time specified in it. It would then require a new API to be added.. thanks, Chenthill. ___ 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
the current value before > > >updating the item. If there is a mismatch, the update is > > >rejected with a suitable error code. > > > * If the values are unset, the update is always executed. > > > > A backend may not have a LAST-MODIFIED property for a particular event > > in this use case: > > a) create a new appointment in the GW calendar (while online) > > b) open the same appointment (before the refresh timeout) > > That's because the local copy of the appointment is not identical to the > one on the server, right? Perhaps the backend could force an immediate > refresh of this particular appointment to get the server's > LAST-MODIFIED? You are right. This is a problem in groupwise backend and not common to all backends. We should be storing the last modified time stored in server as soon as the item is created. There is a problem in the groupwise soap interface that it does not return the created/last-modified time stored on server after creating the item. May be the item has to be fetched again to get these fields. But this is a problem only to groupwise and should be fixed in the backend. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
I was not able to try the upstream libical yet. I am right now packed with some other work, so I will try to get this done as soon as possible. Suddenly the weekends have gone out of my hands as I have to move out of station to places that do not have internet connectivity. Either me or suman will make the changes and get the work done for 2.25.1 if the time is sufficient to get libical as a external dependency for GNOME 2.25.1. We would test the library and let you know before oct 17th. thanks, Chenthill. On Fri, 2008-09-19 at 14:41 +0530, Chenthill wrote: > On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote: > > >> I have applied Chenthill's memory management patches (only to the > > >> 'libical' directory and to the examples -- still have to do the > > >> 'libicalcap' and 'libicalss' directories) using function names ending in > > >> "_r". > > > IMHO, HANDLE_LIBICAL_MEMORY can be removed. > > > > > > > Ok folks, it's done ... > > > > The remaining portions of libical (libicalcap and libicalss) have been > > converted to the "_r" API. (The test suite still uses the old API and > > will continue to do so for a while.) > > > > Now is the time for Evolution code to be updated to use the new calling > > syntax. > > > > Is there anything we can do to facilitate this, or should we just hang > > out and wait for you folks to kick the tires on the new library? Let me > > know... > I will make the changes and test it over this weekend. > > thanks, Chenthill. > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote: > >> I have applied Chenthill's memory management patches (only to the > >> 'libical' directory and to the examples -- still have to do the > >> 'libicalcap' and 'libicalss' directories) using function names ending in > >> "_r". > > IMHO, HANDLE_LIBICAL_MEMORY can be removed. > > > > Ok folks, it's done ... > > The remaining portions of libical (libicalcap and libicalss) have been > converted to the "_r" API. (The test suite still uses the old API and > will continue to do so for a while.) > > Now is the time for Evolution code to be updated to use the new calling > syntax. > > Is there anything we can do to facilitate this, or should we just hang > out and wait for you folks to kick the tires on the new library? Let me > know... I will make the changes and test it over this weekend. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Tue, 2008-09-16 at 09:37 -0400, IGnatius T Foobar wrote: > > Since we do really want to remove the fork and pick up packages from > > upstream, I can change the apis in evolution related packages if a new > > set of apis with some suffix is provided from libical upstream. > > > Many of you have probably already read this on the libical mailing list, > but just in case: > > I have applied Chenthill's memory management patches (only to the > 'libical' directory and to the examples -- still have to do the > 'libicalcap' and 'libicalss' directories) using function names ending in > "_r". For example, icalcomponent_as_ical_string() is now simply a > wrapper around icalcomponent_as_ical_string_r() which places the new > string buffer on the ring before returning it to the caller. The > functions whose names end in "_r" have had Chenthill's memory management > patches applied to them. > > Do we still need to add the HANDLE_LIBICAL_MEMORY hack to make the old > function names act like the new ones? Chenthill's most recent message > (quoted above) seems to imply that the Evolution team is willing to move > to the new function names. Let me know. IMHO, HANDLE_LIBICAL_MEMORY can be removed. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Tue, 2008-09-09 at 18:00 +0200, Patrick Ohly wrote: > On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote: > > Chenthill wrote: > > > So it is better to inform all the stake holders about the change and let > > > them depend on the library versions to decide whether to free the memory > > > or not if they have a need to depend on the older versions of libical. I > > > think no one deny to make the necessary changes knowing that the old API > > > is not very stable. > > > > > > Atleast once I noticed the problem. I made this patch and made all the > > > changes required in evolution, evolution-exchange and > > > evolution-data-server. I would not really like to change them again with > > > new APIS :) > > Although I agree that the new memory model is a vast improvement over > > the existing one, I think you may be underestimating the potential > > effects of telling dozens of downstream projects that they will have to > > rewrite their code *right* *now* in order to continue using libical. > > Many will respond by forking, or staying forked, which as I mentioned > > earlier is exactly the opposite of what we are trying to accomplish. > > I agree. When I started writing the patch, since only the gnome packages which depend on libecal are going be affected. I thought of incorporating changes in all other modules myself since it was just to grep all the apis and free the returned memory. So I had a thinking that all the downstream projects would be ready to change their code during a release time since stability is an issue and change can be done fast. But if it was not the case and might result in forking again, the only solution which I too see is create a new set of API's which uses the new memory allocation. > > > How would you feel about a global flag which tells libical how to > > allocate memory? > > The problem with that is that it is not possible to mix code which uses > the old and the new semantic. For example, a program or library which > uses libical directly, using the old semantic, couldn't be combined with > the Evolution libraries. Yes right. Its not possible to have the old semantic with changed memory allocation. > > To let old and new code coexists I would suggest the following approach: > 1. The Evolution patch gets applied, making the core functions safe > to use. > 2. The function implementations whose semantic has changed get > renamed; I kind of like the _r suffix, but _alloc or _copy would > also work. > 3. Under the old names small wrappers are added which establish the > old behavior again by copying the string into the ring buffer > and freeing the dynamically allocated one: this incurs some > overhead, but usage of these versions of the calls is > discouraged anyway. By using function attributes it would be > possible to trigger deprecation warnings for code which still > uses them. > 4. In the header file both variants are declared. > 5. In addition, ical.h also redefines the old names to the new > names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code > already does that and therefore continues to work with such a > modified upstream libical without source code changes. > > I personally would prefer to avoid step 5 and rather do a search/replace > in Evolution, but Chenthill didn't like that. Since we do really want to remove the fork and pick up packages from upstream, I can change the apis in evolution related packages if a new set of apis with some suffix is provided from libical upstream. The old patch is attached with bug 516408. You can find the patches at, http://svn.gnome.org/viewvc/libical?view=revision&revision=633 and http://svn.gnome.org/viewvc/libical?view=revision&revision=637 thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 23:55 -0400, IGnatius T Foobar wrote: > Patrick Ohly wrote: > > In the upstream libical certain functions return char * pointers into > > memory stored in ring buffers. The caller must not free those pointers. > > The drawback is that the life time of those strings is not predictable. > > > > In the current Evolution libical, those same functions (not renamed!) > > return copies of the string which the caller has to free. Code which was > > written using the old semantic of the calls will leak memory. Code > > adapted to the new semantic (like Evolution) will crash when combined > > with the upstream libical without the same patch. > > > Ok, I definitely see the benefit there. This is similar to POSIX calls > which now offer alternative versions (usually with "_r" appended to the > name) that don't use a static buffer or a ring buffer, in order to be > reentrant? > > If all users of the upstream libical are willing to adapt their code, > > then the best solution would be to simply import the Evolution patch > > into upstream. > > > As much as I'd like to see that happen, I don't think it's realistic. > libical is used by dozens of downstream projects, and a sudden forced > API change is likely to encourage them to fork (or stay forked, if > they've already done so) -- exactly the opposite of the end we are > trying to achieve! > > If there is resistance against that, then we could provide two versions > > of each of these API calls: one with the old name and old behavior and > > one with the new behavior and a name suffix. > That seems more realistic. The alternative might be to offer a global > flag that tells libical to behave one way or the other? (I think > something like that was suggested at some point.) > > While I definitely think the new method of memory allocation makes far > more sense (we'll definitely use it in Citadel, as all of our code is > multithreaded) -- expecting the entire community to perform a "flag day" > API change in lockstep is likely to cause confusion and delay. If we > pursued either the alternate function names or the global flag, is there > likely to be any pushback from the Evolution team? I do not feel having alternate function names would be a better solution. Consider the following API which remains the same before and after the memory fixes, char * icalcomponent_as_ical_string (icalcomponent *icomp); The returned memory from this API was internally handled by libical before and now its given to the caller. Though the return type gives an indication that the memory is owned by caller, it was not the case. So having a new API for this and changing the behavior does not look to be a good solution since the underlying memory allocation had to be changed. Similarly even with other APIs which return const char* values, the memory can be overwritten at any time. While removing the ring buffer return type's of all the APIs had to be changed from const char * to char *. Is it really worth it to have the old unstable APIs which can crash the application randomly ? My answer would be NO. This is not just a problem with multi-threaded programs. The crash could happen once the ring buffer gets full and starts overwriting the used memory. Since we statically link to libical and expose it via libecal, we have updated the library versions of libecal. We have an additional flag check (hack) also for it now with a warning as in http://bugzilla.gnome.org/show_bug.cgi?id=528986 . So it is better to inform all the stake holders about the change and let them depend on the library versions to decide whether to free the memory or not if they have a need to depend on the older versions of libical. I think no one deny to make the necessary changes knowing that the old API is not very stable. Atleast once I noticed the problem. I made this patch and made all the changes required in evolution, evolution-exchange and evolution-data-server. I would not really like to change them again with new APIS :) thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote: > Chenthill wrote: > > On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: > > > > > Hello! > > > > > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of > > > libical on 2008-09-01. The KDE-PIM team has switched to that code for > > > KDE 4.2. > > > > > > On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > > > > > > > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > > > > > > > > I discovered last week that there is an attempt to resurrect libical > > > > > from non-maintainership, merge all of the patches from various forks, > > > > > and start making sane releases again[1]. Are the evolution team as > > > > > whole interested in merging their changes to libical upstream and > > > > > depending on it to be installed when a release is made with all of the > > > > > relevant changes? libical isn't exactly a small library, and > > > > > statically > > > > > linking it is a waste of memory for everyone. > > > > > > > > > I vaguely recall the biggest diff being timezone handling. > > > > > > > Not sure about that. They have merged the "system timezone database > > > conversion" code, if that's what you mean. Unfortunately they missed the > > > recent bug fixes required for that code to handle the upcoming > > > summer->winter time transition. We really should have been more active > > > with keeping them informed about Evolution-libical changes. I have > > > alerted them and the KDE-PIM team of the problem. > > > > > > However, they haven't included the modified memory handling. Considering > > > that this breaks the user space API merging it might be a hard sell. > > > > > > > > > > > I'll happily start working on extracting the changes to EDS and > > > > > pushing > > > > > them into the new libical repository, if the Evolution team as a whole > > > > > agrees that the fork of libical will be dropped. > > > > > > > > +1 > > > > > +1 from my side too. We were discussing about this at > > http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes > > to be merged upstream. We wanted to get this done for 2.26. > > > > thanks, Chenthill > In what way does it break the userspace API? Is it possible that the > API could be extended in such a way that memory handling depends upon > how it's called? All the information/discussion about this is available at, http://bugzilla.gnome.org/show_bug.cgi?id=516408 and http://bugzilla.gnome.org/show_bug.cgi?id=528986 > > We would *really* like to get everyone merged and re-unify this > library once and for all. Everyone would benefit. We provide our support too to get this done!! thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: > Hello! > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of > libical on 2008-09-01. The KDE-PIM team has switched to that code for > KDE 4.2. > > On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > > I discovered last week that there is an attempt to resurrect libical > > > from non-maintainership, merge all of the patches from various forks, > > > and start making sane releases again[1]. Are the evolution team as > > > whole interested in merging their changes to libical upstream and > > > depending on it to be installed when a release is made with all of the > > > relevant changes? libical isn't exactly a small library, and statically > > > linking it is a waste of memory for everyone. > > > > I vaguely recall the biggest diff being timezone handling. > > Not sure about that. They have merged the "system timezone database > conversion" code, if that's what you mean. Unfortunately they missed the > recent bug fixes required for that code to handle the upcoming > summer->winter time transition. We really should have been more active > with keeping them informed about Evolution-libical changes. I have > alerted them and the KDE-PIM team of the problem. > > However, they haven't included the modified memory handling. Considering > that this breaks the user space API merging it might be a hard sell. > > > > I'll happily start working on extracting the changes to EDS and pushing > > > them into the new libical repository, if the Evolution team as a whole > > > agrees that the fork of libical will be dropped. > > +1 +1 from my side too. We were discussing about this at http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes to be merged upstream. We wanted to get this done for 2.26. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
Patrick, On Mon, 2008-09-01 at 19:55 +0200, Patrick Ohly wrote: > On Thu, 2008-08-21 at 12:37 +0530, Chenthill wrote: > > Thanks, I will send out a mail to the list mentioning the critical > > fixes which have gone in recently in the stable branch which needs to be > > taken into the distro's. > There is one additional fix which I would recommend for timezones, http://svn.gnome.org/viewvc/libical?view=revision&revision=645 . - Chenthill. > Bug #548268 is in trunk (thanks Chenthill!) and tested automatically > now. The test showed that the time zones in South America and Australia > were also affected. > > I think we should send out that bug list to the distributors ASAP. > Debian Etch is already frozen. Chenthill, do you have the list ready and > can you send it both to this list and the distributor list? > > My own proposal for inclusion are > * 548268: time zone conversion incorrect > * 546934: [Exchange Connector] contact change tracking is broken > (required by SyncEvolution) > * 499932: [Bug 499932] Not deleting from e-mail server after specified > time > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
andre, Thanks, I will send out a mail to the list mentioning the critical fixes which have gone in recently in the stable branch which needs to be taken into the distro's. thanks, Chenthill. On Wed, 2008-08-20 at 13:12 +0200, Andre Klapper wrote: > Am Sonntag, den 24.08.2008, 11:48 +0530 schrieb Chenthill: > > Where can I get the distributors list to inform them ? I know some > > individual email ids, but not sure if its a complete list. > > http://mail.gnome.org/mailman/listinfo/distributor-list > > andre ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
On Tue, 2008-08-19 at 22:32 +0530, Srinivasa Ragavan wrote: > Patrick > > Evolution follows GNOME release cycles, which has just three dot > releases on the stable branch (2.22.3). And after that only for > DoS/Vulnerability fixes there will be dot releases. Distros shipping > 2.22.x will pick patches from trunk/2.22.x and apply as and when > required. (Atleast for OpenSUSE, I/my team does that). Im sure > Ubuntu/Fedora too does the same. > > If it is a really issue, may be mailing the distributors list on picking > some patches for Evo/Eds may help. Where can I get the distributors list to inform them ? I know some individual email ids, but not sure if its a complete list. - Chenthill. > > -Srini. > > On Tue, 2008-08-19 at 18:41 +0200, Patrick Ohly wrote: > > Hello, > > > > I have a question primarily to the maintainers of the various Linux > > distributions which include Evolution 2.22.x (Ubuntu 8.04 LTS, Debian > > Lenny), but also to the Evolution hackers: the latest stable release, > > 2.22.3.1, still contains bugs. There are different ways to deal with > > this: > > 1. Evolution upstream continues to apply bug fixes to the 2.22.x as > > long as important distributions use that. > > 2. Maintainers of packages apply patches locally, without or with > > help by Evolution upstream. Upstream could help with bug > > tracking. > > > > What's the current practice? It seems that upstream has already stopped > > updating the 2.22 branch and bug fixes are only applied to trunk [1]. > > > > I'm bringing this up because at least one of the bugs will become > > critical in September: as noted this week [2], the conversion of system > > time zone information into libical time zone information (as used by > > Evolution) yields an end of summer time which is one week too early for > > Western Europe. It might also be incorrect for other countries and for > > the beginning of summer time. > > > > That's particularly disappointing because the work on improving time > > zone support [2] was supposed to solve such issues. Now it looks like > > Evolution will fail to display events at the right time - once again! > > > > In addition to this problem I'm sure there are other bugs which could be > > included in another 2.22.x release. The broken Exchange Connector > > contact change tracking [1] is one example. > > > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=546934#c2 > > [2] http://bugzilla.gnome.org/show_bug.cgi?id=548268 > > [3] http://www.estamos.de/blog/2008/06/22/time-zone-handling-in-evolution/ > > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel-db-summary changes merged to Trunk
This is great!! I am updating the code now and will test it out :-) - Chenthill. On Thu, 2008-07-17 at 00:03 +0530, Sankar wrote: > Hi , > > As many of you know, Srini and I were working on a branch > camel-db-summary (codenamed Madagascar). > > This is now merged with trunk. Please see > http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9125 > > This adds a new dependency on sqlite. So, you need to have sqlite devel > packages installed. > > You will have to update evolution and evolution-exchange packages as > well. > > As of now, evolution-exchange has some crashers connecting with the > exchange servers. > > Some of the quick-show items like (recent messages) does not work. > > Meta summary code is wiped out and hence new mails are not beagle > searcheable. > > But, we promise we will fix them soon :-) > > > Any other feedback or issues, that you get, please ping us in > #evolution. > > I will be sending out a detailed description of what we have done and > what is pending, soon. > > Thanks. > > -- > Sankar > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] time zone problem: extending API instable branch?
Hi Srini, The patches are available at comment #4. The two new files e-cal-check-timezones.[ch] which adds new API's. - Chenthill. >>> Srinivasa Ragavan <[EMAIL PROTECTED]> 06/13/08 8:44 AM >>> Patrick, Can you just point us to the right patch, that extends API ? I seem to hit the wrong patch. I dont see any .h changes also. Is there a way, we can work around for stable branch alone? We may need release team approval, if we have to update API (I guess so, though EDS isn't part of platform, we may have to atleast check with them) -Srini. On Thu, 2008-06-12 at 22:25 +0200, Patrick Ohly wrote: > Hello, > > the patch that I am suggesting to fix the time zone issues in Evolution > (see http://bugzilla.gnome.org/show_bug.cgi?id=528902) adds new > functions to libecal. Note that the extended library is backwards > compatible, i.e., this is not an API change which requires recompiling > other programs (http://bugzilla.gnome.org/attachment.cgi?id=112638). > > Is this an acceptable solution for the 2.22.x stable branch? Chentill > reviewed the patch and agreed to committing it on trunk after some minor > changes (which I have done in the meantime), but he is concerned about > the API and rather would like to keep this out of the stable release. > > I'm writing here to also get the opinion of Evolution packagers who > might not monitor the discussion taking place in the bug tracker. Is > this issue important enough to extend the API in the next 2.22.x > release? If Evolution upstream doesn't include it in 2.22.x, are > distributions going to apply the patch (it is written against the stable > branch and applies cleanly) anyway? > > I personally think that this is important because Evolution will > continue to use out-dated time zone definitions for new meetings in > perpetuity unless people wipe out their old calendars or the patch is > applied. Quoting Paul Smith, who missed a meeting this spring due to > this bug: > I have to add my voice to those saying "please, please, PLEASE > someone fix this complete and utter disaster! > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] query string format
On Thu, 2008-05-08 at 11:57 -0400, Bill Filler wrote: > Hello, > Can anyone explain how to format a query string for > e_cal_get_object_list() that gets ALL tasks in the system_tasks() database? > I tried "#t" and that works for initial query, but then only returns new > tasks after that when I run it again and I need to get all tasks again. > I couldn't find any doc on the query string format. Any help would be > appreciated. Thanks Using "#t" as a search expression should provide all the tasks in each call to e_cal_get_object_list. It tested to see if there is any bug in it, but it seems to work fine. I think the clock applet also uses the same to display the tasks. - Chenthill. > > Bill > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Tue, 2008-04-15 at 18:07 +0200, Patrick Ohly wrote: > On Tue, 2008-04-15 at 13:59 +0530, chenthill wrote: > > To preserve the timezone history, the best way would be to store the old > > rules in VTIMEZONES which should be done in libical. > > If I understand you correctly, you are suggesting to merge a VTIMEZONE > with TZID=FOO that comes with a new meeting invitation with a previously > stored VTIMEZONE with the same TZID, so that the merged VTIMEZONE has > the rules from both the original VTIMEZONE. > > The problem is that incoming VTIMEZONE definitions from Exchange do not > contain information to which year the rules apply. In the examples that > I quoted, both use DTSTART:16010101T02 and thus are mutually > exclusive. Nope I don't mean merging here. The VTIMEZONE from libical currently do not provide the history of timezone changes (older + current rrules) for the system timezones. Libical should be modified so that the VTIMEZONE's generated stores the timezone history. The Tzfile would have the history stored on the system, libical just does not store it in VTIMEZONE. Say if a meeting is received from exchange server with some Tzid for America/New_York. As we discussed below, this needs to be mapped to system timezone and libical should provide the VTIMEZONE which has the timezone history. This way, we need not use the VTIMEZONE sent by exchange and still display the older/current events properly. > > > I do not recommend having another set of tzid's with > > versions in it for maintaining the old rules. This would trigger the > > comparison of rules between different versions of timezones. > > I don't get this part. Can you elaborate what you mean? Are you saying > that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts > with an existing VTIMEZONE should be avoided? yes, if libical is modified to return VTIMEZONE with the history and once mapping between "foreign" timezones to system timezones is done at the backend, this is would not be required. All the older events would be properly displayed. > > > Once the > > outlook timezones are mapped with libical ones, the libical timezones > > which would have the old rules can be used. > > Mapping "foreign" TZIDs to system timezones always should be attempted > first. Storing a VTIMEZONE under a different name is only the fallback. > > > > [VTIMEZONE and VEVENT are added separately] > > > > I don't think it works like that. iirc the whole VCALENDAR (used as > > > > top-level component in itip-formatter) which has events and timezone > > > > gets passed to the backend, the backend adds the timezone and events to > > > > the cache, notifies the UI. > > > > > > After looking at the Evolution source code I already came to the same > > > conclusion. However, clients like SyncEvolution do add VTIMEZONE and > > > VEVENT separately. That is necessary because the UID of each new VEVENT > > > is required immediately, which is not possible (or at least very > > > awkward) via ecal_receive_objects(). > > I hope SyncEvolution is the only backend which does it in this way. > > SyncEvolution is not a backend. It is a client program using the > synchronous libecal API. Ah ok. I misunderstood that it has a corresponding external backend as well. > > I believe OpenSync works the same way, although I haven't looked at it > during the last two years. > > > I am > > not sure if we would need a libecal API for this. Is it not possible to > > handle it inside e_cal_backend_add_timezone? > > No, because the call cannot return the information to which TZID the > timezone was mapped. Modifying the "icaltimezone *zone" would be an API > change. The tzid need not be changed for the VEVENT. The following would work fine even if VTIMEZONE and VEVENT are handled separately, e_cal_backend_add_timezone - Add the timezone to backend's cache if the timezone cannot be matched with the system timezone else do not add. e_cal_backend_get_timezone - use the mapping and provide proper system timezone or if its unable to map, it needs to get the timezone from the cache. The clients can now use the corresponding libecal API's to get the right timezone. So, I feel this can be done commonly to all backends at EDS. > > > Yeah you can get the code after two weeks, not a problem. Please file a > > bug on this since the old bug is about, outdated evolution timezones > > which is obsolete now as we pickup the timezones from the system. The > > bug also has a too many comments already. Probably we can also schedule > > a meeting on irc and have a discussion on this. Please let
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Fri, 2008-04-11 at 23:31 +0200, Patrick Ohly wrote: > On Fri, 2008-04-11 at 00:55 -0600, P Chenthill wrote: > [Exchange calendar backend patch] > > In cases of exchange the old VTIMEZONE and the new VTIMEZONE would have > > the same tzid, only the rules would be different. All events old and new > > will just use the latest timezone from the backend since they would have > > the same tzid in their start/end dates. > > And that would be wrong for the old events which are truly in the past. > Consider the 2006 example that I sent: when viewing the year 2006 in the > calendar, the system timezone definition is used and thus Evolution > correctly uses the summer saving rules from 2006. Using the updated > VTIMEZONE for events in that year would lead to a one hour shift during > those weeks where old and new rules differ. > > It's arguably the lesser evil for recurring events because the current, > still relevant recurrences would be displayed correctly, so there is > some value in it. But for old events which are archived for reference > purposes it would be just wrong. What I am suggesting would solve this > problem by preserving both the old and the new VTIMEZONE. > > For recurring events the mapping to the more complex system timezone > definitions helps. To preserve the timezone history, the best way would be to store the old rules in VTIMEZONES which should be done in libical. Since exchange does not like it, the older rules should be stripped off while sending the timezones to the exchange server at the backend and libical should facilitate this. I do not recommend having another set of tzid's with versions in it for maintaining the old rules. This would trigger the comparison of rules between different versions of timezones. Once the outlook timezones are mapped with libical ones, the libical timezones which would have the old rules can be used. > > [VTIMEZONE and VEVENT are added separately] > > I don't think it works like that. iirc the whole VCALENDAR (used as > > top-level component in itip-formatter) which has events and timezone > > gets passed to the backend, the backend adds the timezone and events to > > the cache, notifies the UI. > > After looking at the Evolution source code I already came to the same > conclusion. However, clients like SyncEvolution do add VTIMEZONE and > VEVENT separately. That is necessary because the UID of each new VEVENT > is required immediately, which is not possible (or at least very > awkward) via ecal_receive_objects(). I hope SyncEvolution is the only backend which does it in this way. I am not sure if we would need a libecal API for this. Is it not possible to handle it inside e_cal_backend_add_timezone ? I don't know much about how SyncEvolution handles it. While considering with all the other backend's in mind which are under EDS, exchange, I don't feel the need. > > This makes the new function a bit more compleyoutube.com/TuxSkyNetx, but I > still think it is > doable to come up with a solution which can be used by backends and > clients. Attached is a proposal. In SyncEvolution I would lookup > existing VTIMEZONE in the calendar via the e_cal_tzlookup_ecal() utility > function, which then uses e_cal_get_timezone(). > > I checked the code of the file backend. The e_cal_check_timezone() call > would fit right before the icalcomponent_merge_component() call and > would use the other tzlookup function which checks against local > VTIMEZONE components. > > All the other backends would have to be adapted in a similar way. I > considered modifying the general e_cal_backend_file_receive_objects(), > but decided against it because individual backends might have better > ways of dealing with the problem. I also don't want to touch code which > I cannot test. > > I will be out of town for three days. If there are no objections, then > I'll try to get working code together when I come back, hopefully before > I go on a business trip for two weeks the week after. Time, anyone got > some time? Yeah you can get the code after two weeks, not a problem. Please file a bug on this since the old bug is about, outdated evolution timezones which is obsolete now as we pickup the timezones from the system. The bug also has a too many comments already. Probably we can also schedule a meeting on irc and have a discussion on this. Please let me know the time which would be suitable for you. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Wed, 2008-04-09 at 00:42 +0200, Patrick Ohly wrote: > On Mo, 2008-04-07 at 23:40 -0600, P Chenthill wrote: > > On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote: > > > One could argue that the sending program is at fault: it could have used > > > a different TZID after changing the timezone definition. Alternatively > > > it could have sent a more complex VTIMEZONE which also includes the > > > historic rules. I believe both causes other problems in practice. > > > Speculating about it is futile anyway and won't change the meeting > > > invitations that Evolution has to deal with. > > > > > > Besides, don't blame Outlook too much: Evolution >= 1.12 now does > > > exactly the same thing. For example, a meeting invitation now uses > > > "/softwarestudio.org/Tzfile/America/Los_Angeles" and only includes the > > > current rules for daylight saving transitions. > > It just includes the current rules for outlook compatibility. > > Yep, that's the "I believe both causes other problems in practice" > part ;-) > > > I am just back after a small vacation. > > Ah, that explains the silence. I'll be away over the weekend and Monday > myself and don't know whether I'll have time before I came back. > > > I dont think anyone is work on this issue currently. I made a patch for > > exchange backend for solving this issue long time back. But > > unfortunately its not committed in trunk. > > Why? Technical issues that I should be aware of? I think it was postponed to commit after some freeze and missed later. I don remember the exact reasons. I am sure, its not due to any technical reasons :-) > > It uses a timestamp in the > > VTIMEZONE file to store the latest one always. By this way we would also > > know the last time period when the timezone has been changed for that > > location. > > I can't claim to understand the patch or the code that it applies to. > When you say that only the latest VTIMEZONE is stored, that implies that > only one is stored, right? How does that solve the problem of having an > event in the calendar which depends on an old revision of the VTIMEZONE > and another one which needs the current revision? The cache would have only one version of the timezone at any point since the tzid is used as a uid for the VTIMEZONE components for storing them. The X-EVOLUTION-TZ-TIMESTAMP would be used to ensure that only the latest VTIMEZONE is stored. Since the UI would pick the timezone from the backend, it would get the right timezone. In cases of exchange the old VTIMEZONE and the new VTIMEZONE would have the same tzid, only the rules would be different. All events old and new will just use the latest timezone from the backend since they would have the same tzid in their start/end dates. > > > I am ok with handling using the sequence numbers. I am not sure whether > > a new libecal API would be needed to solve this, since the timezones > > would be handled at the backend. > > The client adds the VTIMEZONE and some time later the corresponding > event. At that time the backend won't be able to correlate the two, but > that is necessary to change the TZID in the event if the VTIMEZONE was > stored with a different TZID. Only the client can do that. I don't think it works like that. iirc the whole VCALENDAR (used as top-level component in itip-formatter) which has events and timezone gets passed to the backend, the backend adds the timezone and events to the cache, notifies the UI. This is the same behavior while accepting and importing events. Another reason why this has to be handled in backend is, there can be cases when the user can accept events using some other client and receive the events through the respective backends. So handling it in the backend would be better. Atleast above is the behavior w.r.t exchange, and other backends under EDS. > > > It would be better to handle all the timezones in a common place inside > > EDS. The reason for that is, same timezones can exist in multiple > > calendars which could not be matched to either system timezone or > > through the fuzzy logic. Currently it is handled separately for every > > calendar and the same information is stored redundantly. Another issue > > which should be taken care of is, the system timezones should not be > > stored in the cache. They should always be taken from the libical > > builtin timezone. Please consider these too while implementing the > > solution. > > That's way beyond what I have time for, sorry. Besides, I want to keep > my changes as small as possible to increase the chance of getting them > into the stable branch. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
rename the new timezone by attaching " ".
> Repeat the check and renaming until a 100% match is found or the
> timezone can be stored without colliding with an existing timezone. Then
> proceed with importing the event with renamed TZIDs.
>
> I believe that this could be implemented without changing anything in
> libecal. I could implement it as part of SyncEvolution, but that won't
> solve the problem when Evolution itself imports events. A new API call
> in libecal would be a better solution.
> Before I proceed, let me ask: are there other plans to tackle the
> problem? Is someone working on it? Similar questions in #301363 were not
> answered.
>
> Do you agree with the outlined plan in principle? If no-one else is
> working on it and you agree, then I would describe the new API call in
> more detail and see whether I can get it implemented. I would reuse the
> same code in SyncEvolution in order to improve the situation with older
> Evolution releases and to avoid depending on an extended libecal in the
> binary releases.
I am just back after a small vacation.
I dont think anyone is work on this issue currently. I made a patch for
exchange backend for solving this issue long time back. But
unfortunately its not committed in trunk. It uses a timestamp in the
VTIMEZONE file to store the latest one always. By this way we would also
know the last time period when the timezone has been changed for that
location. Have attached the patch for a reference.
I am ok with handling using the sequence numbers. I am not sure whether
a new libecal API would be needed to solve this, since the timezones
would be handled at the backend. Overall I can understand the approach
and it seems good.
It would be better to handle all the timezones in a common place inside
EDS. The reason for that is, same timezones can exist in multiple
calendars which could not be matched to either system timezone or
through the fuzzy logic. Currently it is handled separately for every
calendar and the same information is stored redundantly. Another issue
which should be taken care of is, the system timezones should not be
stored in the cache. They should always be taken from the libical
builtin timezone. Please consider these too while implementing the
solution.
>
> What is the timeline for this? 2.22 is released; if this version is
> picked up by distributions unpatched, then we are bound to run into the
> same problems again end of 2008 and probably also 2009.
If there are no interface changes, we can definitely take the patch in
for stable branch. Please come up with the initial design and once the
patch is ready, we can also look at requesting for a freeze break to get
the patch in for the stable branch also.
- Chenthill.
Index: calendar/e-cal-backend-exchange.c
===
--- calendar/e-cal-backend-exchange.c (revision 1330)
+++ calendar/e-cal-backend-exchange.c (working copy)
@@ -1094,6 +1094,27 @@
return priv->default_timezone;
}
+static icaltimetype
+get_timestamp_from_tzcomp (icalcomponent *icalcomp)
+{
+ icalproperty *icalprop;
+ icaltimetype dtstamp = icaltime_null_time ();
+
+ for (icalprop = icalcomponent_get_first_property (icalcomp,
ICAL_X_PROPERTY); icalprop != NULL;
+ icalprop = icalcomponent_get_next_property (icalcomp,
ICAL_X_PROPERTY)) {
+ const char *name = icalproperty_get_x_name (icalprop);
+
+ if (name && g_str_equal (name, "X-EVOLUTION-TZ-TIMESTAMP")) {
+ const char *value = icalproperty_get_x (icalprop);
+ dtstamp = icaltime_from_string (value);
+ break;
+ }
+ }
+
+ return dtstamp;
+}
+
+
ECalBackendSyncStatus
e_cal_backend_exchange_add_timezone (ECalBackendExchange *cbex,
icalcomponent *vtzcomp)
@@ -1109,9 +1130,19 @@
return GNOME_Evolution_Calendar_InvalidObject;
tzid = icalproperty_get_tzid (prop);
d(printf("ecbe_add_timezone: tzid = %s\n", tzid));
- if (g_hash_table_lookup (cbex->priv->timezones, tzid))
- return GNOME_Evolution_Calendar_ObjectIdAlreadyExists;
+ if ((zone = g_hash_table_lookup (cbex->priv->timezones, tzid))) {
+ icalcomponent *tzcomp_old;
+ icaltimetype dtstamp_old, dtstamp_new;
+ tzcomp_old = icaltimezone_get_component (zone);
+
+ dtstamp_old = get_timestamp_from_tzcomp (tzcomp_old);
+ dtstamp_new = get_timestamp_from_tzcomp (vtzcomp);
+
+ if (icaltime_is_null_time (dtstamp_new) ||
(!icaltime_is_null_time (dtstamp_old) && icaltime_compare (dtstamp_new,
dtstamp_old) <= 0))
+ return GNOME_Evolu
Re: [Evolution-hackers] cleaning up the timezone handling mess
rename the new timezone by attaching " ".
> Repeat the check and renaming until a 100% match is found or the
> timezone can be stored without colliding with an existing timezone. Then
> proceed with importing the event with renamed TZIDs.
>
> I believe that this could be implemented without changing anything in
> libecal. I could implement it as part of SyncEvolution, but that won't
> solve the problem when Evolution itself imports events. A new API call
> in libecal would be a better solution.
> Before I proceed, let me ask: are there other plans to tackle the
> problem? Is someone working on it? Similar questions in #301363 were not
> answered.
>
> Do you agree with the outlined plan in principle? If no-one else is
> working on it and you agree, then I would describe the new API call in
> more detail and see whether I can get it implemented. I would reuse the
> same code in SyncEvolution in order to improve the situation with older
> Evolution releases and to avoid depending on an extended libecal in the
> binary releases.
I am just back after a small vacation.
I dont think anyone is work on this issue currently. I made a patch for
exchange backend for solving this issue long time back. But
unfortunately its not committed in trunk. It uses a timestamp in the
VTIMEZONE file to store the latest one always. By this way we would also
know the last time period when the timezone has been changed for that
location. Have attached the patch for a reference.
I am ok with handling using the sequence numbers. I am not sure whether
a new libecal API would be needed to solve this, since the timezones
would be handled at the backend. Overall I can understand the approach
and it seems good.
It would be better to handle all the timezones in a common place inside
EDS. The reason for that is, same timezones can exist in multiple
calendars which could not be matched to either system timezone or
through the fuzzy logic. Currently it is handled separately for every
calendar and the same information is stored redundantly. Another issue
which should be taken care of is, the system timezones should not be
stored in the cache. They should always be taken from the libical
builtin timezone. Please consider these too while implementing the
solution.
>
> What is the timeline for this? 2.22 is released; if this version is
> picked up by distributions unpatched, then we are bound to run into the
> same problems again end of 2008 and probably also 2009.
If there are no interface changes, we can definitely take the patch in
for stable branch. Please come up with the initial design and once the
patch is ready, we can also look at requesting for a freeze break to get
the patch in for the stable branch also.
- Chenthill.
Index: calendar/e-cal-backend-exchange.c
===
--- calendar/e-cal-backend-exchange.c (revision 1330)
+++ calendar/e-cal-backend-exchange.c (working copy)
@@ -1094,6 +1094,27 @@
return priv->default_timezone;
}
+static icaltimetype
+get_timestamp_from_tzcomp (icalcomponent *icalcomp)
+{
+ icalproperty *icalprop;
+ icaltimetype dtstamp = icaltime_null_time ();
+
+ for (icalprop = icalcomponent_get_first_property (icalcomp,
ICAL_X_PROPERTY); icalprop != NULL;
+ icalprop = icalcomponent_get_next_property (icalcomp,
ICAL_X_PROPERTY)) {
+ const char *name = icalproperty_get_x_name (icalprop);
+
+ if (name && g_str_equal (name, "X-EVOLUTION-TZ-TIMESTAMP")) {
+ const char *value = icalproperty_get_x (icalprop);
+ dtstamp = icaltime_from_string (value);
+ break;
+ }
+ }
+
+ return dtstamp;
+}
+
+
ECalBackendSyncStatus
e_cal_backend_exchange_add_timezone (ECalBackendExchange *cbex,
icalcomponent *vtzcomp)
@@ -1109,9 +1130,19 @@
return GNOME_Evolution_Calendar_InvalidObject;
tzid = icalproperty_get_tzid (prop);
d(printf("ecbe_add_timezone: tzid = %s\n", tzid));
- if (g_hash_table_lookup (cbex->priv->timezones, tzid))
- return GNOME_Evolution_Calendar_ObjectIdAlreadyExists;
+ if ((zone = g_hash_table_lookup (cbex->priv->timezones, tzid))) {
+ icalcomponent *tzcomp_old;
+ icaltimetype dtstamp_old, dtstamp_new;
+ tzcomp_old = icaltimezone_get_component (zone);
+
+ dtstamp_old = get_timestamp_from_tzcomp (tzcomp_old);
+ dtstamp_new = get_timestamp_from_tzcomp (vtzcomp);
+
+ if (icaltime_is_null_time (dtstamp_new) ||
(!icaltime_is_null_time (dtstamp_old) && icaltime_compare (dtstamp_new,
dtstamp_old) <= 0))
+ return GNOME_Evolu
