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 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
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
[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 dvra...@redhat.com 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] 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] 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] 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] [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
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
[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
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 - 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
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] 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] [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 pochere...@src.gnome.com 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] 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
, \ 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 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 :) 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] 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] 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 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] 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
[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] New 'eclient' branch in eds
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes mbar...@redhat.com 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); * We should use GIO error codes whenever possible, and I see quite a bit of overlap here. I think following error codes should be dropped: E_CAL_CLIENT_ERROR_SUCCESS E_BOOK_CLIENT_ERROR_SUCCESS There's no need for an error code for successful operations. E_CAL_CLIENT_ERROR_INVALID_ARG E_BOOK_CLIENT_ERROR_INVALID_ARG Use G_IO_ERROR_INVALID_ARGUMENT. E_CAL_CLIENT_ERROR_BUSY E_BOOK_CLIENT_ERROR_BUSY Use G_IO_ERROR_BUSY
Re: [Evolution-hackers] EWS MessageInfo leak wtf
On Sat, Apr 9, 2011 at 4:08 AM, David Woodhouse dw...@infradead.org 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] EDS improvements for MeeGo
On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote: On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly patrick.o...@gmx.de wrote: Hello! I have published some more information about our plans for MeeGo: http://wiki.meego.com/Architecture/planning/evolution-data-server http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements I was going through the eds-improvements part of it. In the performance improvement mentioned at 'Optional parsing of data in the client'. I was wondering if having a new lib[ecal/ebook] api that can return two kind of meta data, + one for populating the view [similar to message-info in mailer] + for querying the changed information [mentioned at 'change tracking+ atomic updates' section'. I don't quite follow. Can you be more specific? I was suggesting to pass the summary-info required for the view as a dbus object (which requires creation of an object similar to CamelMessageInfo) which could save string-vcard convertions and vice-versa in eds and also remove the need for delayed parsing. 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] Maintenance fork for Evolution / EDS 2.32
On Mon, Apr 4, 2011 at 12:23 PM, Milan Crha mc...@redhat.com 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
[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] Sqlite cache for address-book storage in EDS
On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams awill...@opengroupware.us wrote: On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com 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] Branch date?
On Tue, Mar 15, 2011 at 3:07 AM, Matthew Barnes mbar...@redhat.com 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 Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com 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
[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] [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 mbar...@redhat.com 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
Re: [Evolution-hackers] (no subject)
On Wed, Feb 9, 2011 at 7:40 PM, thilagaraj thilak tk.thilaga...@gmail.comwrote: 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 pchenth...@novell.com 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 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
Re: [Evolution-hackers] Camel Manifesto
. 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. chen Lets get started in another minute and have a small discussion to know whats happening and moving further with coming releases mcrha releases, hmm chen mcrha, yup we have 2.28.1 and 29.1 coming this month * mcrha was hoping in the upcoming year forecast :) abharath ;) chen lol step by step chen as we all know dbus calendar has been merged now mcrha yeah, one big step, then few small steps chen and i would like lakhil to play a major part in bringing the major bugs during every meeting chen and we can share the bugs among us assigning and making sure the issues are fixed before the release lakhil chen, i keep sharing in irc daily ... though i will try to prepare one for meeting * mcrha noticed flood of those yesterday chen prolly we can discuss over bugs like https://bugzilla.gnome.org/show_bug.cgi?id=557613 chen to ensure they are fixed on time chen lakhil, bring it to light and discussing it would make sure these go in before the release lakhil yeah, sure chen lakhil, would be great if you have a list before us during these meetings :) chen mcrha, and coming on patch reviews, chen know there are lot of ur patches waiting on the same mcrha actually, i changes a strategy slightly chen mcrha, can all the patches which are straight forward or if your confident on the fixes be committed directly ? chen and consult on the fixes where you have some doubt.. mcrha I attach patches for test or review, if reporter can try the patch and says ok, then I commit mcrha chen, yup, i can do that, I was hoping in starting with that on January, though chen mcrha, oh why ? chen mcrha, prolly you can attach the patch marking it as committed right away mcrha just for fun of attaching patches to bugzilla. mcrha does it worth it? chen mcrha, and the left ones means that they are requiring some review comment chen mcrha, don think so mcrha 'don' ~~ don't? chen ok don't :) mcrha just clarifying a meaning. mcrha I do not think it worth it too, the commit ID should be enough there chen mcrha, i would say testing from the reporter is fine, but commit it if you feel the approach taken is correct chen mcrha, agree mcrha you know the code will be quite different when you allow me to commit without asking, right? chen mcrha, well we have all spent enough time to make a judgement whether the approach is right or wrong chen and of-course having a review is always better, but considering the ammount of people we have now chen we will not be able to follow the same style mcrha right, that's a bad thing (low human resources) chen mcrha, so if you have patches, chen which are on the above category commit them! chen i mean for the patches right now in the bugzilla as well * mcrha is wondering how chen means 'if' :) lakhil :D abharath :D * chen leaves the rest to mcrha :) mcrha patches in bugzilla, I miss the user statistic page there lakhil mcrha, now it's added back abharath haha and lakhil the points page :D chen lol lakhil all are back :D mcrha chen, I'll go the safe side, killing master only abharath aah :D abharath mcrha: lol mcrha lakhil, is the statistics page back? abharath you the one who has to save the killing :D chen mcrha, ok, hold it on stable as well by ur judgement lakhil mcrha, yep mcrha lakhil, good, let me look how I stand for past few weeks ;) chen to update what i have been doing, mcrha chen, yeah, stable is a different story lakhil https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html chen committed the imapx
[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] 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
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
Am including nirav in the thread. He is working on with the novell IST 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] 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
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] 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] 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 seb128 srag: hi seb128 srag: you 2.26 to be 2.28 and 2.27 to be unstable is a very not cool idea! seb128 your seb128 srag: it basically means let's screw all those who track GNOME 2.27 and have already updated to 2.27.n xkahn ! The final composer addressbook bug seems to be related to whether the data has finished loading when you press enter. * nxvl has quit (leaving) srag hey seb128 * cosimoc (~cosi...@jalfrezi.collabora.co.uk) has joined #evolution xkahn no... I can't reproduce... xkahn :( srag 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) srag 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 andre 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. andre but i think that's discussed by the evo team andre seb128, ^^ chen 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 chen * cache rewrite - http://www.go-evolution.org/CalendarStore , chen Gsoc eds optimization patches and google calendar replaced by caldav at the backend andre so who maintains the addressbook and can finally review 556061? srag andre, chen but that leaves master out of testing for quite some time. chen 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.. srag its as simple as merging late. chen srag, so if these are covered, i have no issues :) andre srag: well, distros are free to package master for testing srag chen, the patches ? andre kill-bonobo is available for fedora andre ubuntu can also package it hggdh er andre er? chen 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 chen as a reply back to thread.. srag andre, but honestly, people won't use it, unless its the *official* version hggdh andre, yes, I guess we could. But it will be a PPA release, not a main srag chen, we can take up that.. not a problem. andre hggdh, sure srag andre, Im fine to have both 2.27.x and 2.26.x released till 3.0 comes out.. chen 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.. andre srag, encourage people to do so hggdh srag, the issue is we already delivered 2.27.3 to Karmic, going back will be a pain andre there's blogs and mailing lists. srag hggdh, if its a matter of version, we can work that out.. cache shouldn't be a problem. srag hggdh, but I understand your issue andre 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) srag 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 :( hggdh andre, +1 andre srag, what is it? srag the master branch srag Im trying to recall something that happened with gdm, dont know the exact releases/numbers andre archlinux and debian still ship gdm 2.20 in their current unstable andre i don't think it's that similar though srag not similar, but would be great, if distros ship 2.27.x and together with 2.26.0
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
[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] 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
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
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] concurrent modifications of items in GUI and EDS database
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] 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-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=revisionrevision=633 and http://svn.gnome.org/viewvc/libical?view=revisionrevision=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 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] 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] 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=revisionrevision=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] 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=revisionrevision=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] 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 me know the time which would be suitable for you. I'll create a new bug report. Should we move the discussion away from this list? I think if we discuss this on IRC, we can conclude on the design faster. It would be better to do the patch reviews in bugzilla. Usually we could meet on IRC during the evening CEST, but there's not much time this week. I may not be available over next week. Let me know a suitable time during this week or after April 28th. - Chenthill
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
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_Evolution_Calendar_ObjectIdAlreadyExists;
+ }
+
zone = icaltimezone_new ();
if (!icaltimezone_set_component (zone, icalcomponent_new_clone
(vtzcomp))) {
icaltimezone_free (zone, TRUE);
Index: calendar/e-cal-backend-exchange-calendar.c
===
--- calendar/e-cal-backend-exchange-calendar.c (revision 1330)
+++ calendar/e-cal-backend-exchange-calendar.c (working copy)
@@ -65,12 +65,25 @@
static void update_x_properties (ECalBackendExchange *cbex, ECalComponent
*comp);
static void
-add_timezones_from_comp (ECalBackendExchange *cbex
Re: [Evolution-hackers] Ical (WebDAV) Web-Calendar read-only!?
Hi Arthur, On Fri, 2007-11-30 at 11:31 +0100, Artur Mücke wrote: Hi, does anyone know if there is a plan when web-calendars will be implemented as writable in Evolution? I am asking because I want to use Evolution as client for my OpenXchange Server that is working with iCal-Calendars. Unfortunately OpenXchange doesnt have any CalDAV implementation so I am kind of dependent to the ical-support. Does anyone know if/when iCal calendars will be writable in Evolution!? It should not be a very big effort to make the web-calendars writable. If someone is ready to work on it, I can guide them. If someone takes it up, prolly we can have in the evolution-2.22 release (next major release) itself. -Chenthill. Would be glad about some answers. Cheers, Artur ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Call for Release Notes
On Mon, 2007-08-27 at 10:01 +, Srinivasa Ragavan wrote: * System Timezone Integration Does this mean that evolution no longer asks the user for their timezone at first use? Are there any other user-noticeable changes? Currently evolution maintains its own timezone files. For every change in the zonefino, we would need to update the timezone's maintained. Now with the system timezone integration, we pickup the timezones from the system, this update from evolution is not required. Evolution would pick the latest timezone's from the system. There are no user-noticeable changes. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] comma-separation of event CATEGORIES
Hi Patrick, On Sun, 2007-06-24 at 18:28 +0200, Patrick Ohly wrote: Hello, I got a report that SyncEvolution does not handle CATEGORIES correctly in ical 2.0 events when multiple categories are specified. It turned out that Evolution or more likely, libical, import/export such events with the comma separator escaped like this: CATEGORIES:Anniversary\,Holiday RFC 2445 specifies CATEGORIES with a normal comma as separator and gives this example: CATEGORIES:APPOINTMENT,EDUCATION When importing such an event, Evolution stores it with two different category properties and then only uses the later one in the GUI: CATEGORIES:APPOINTMENT CATEGORIES:EDUCATION At first glance there doesn't seem to be an open bug related to this; it still happens with Evolution 2.10. I will open a bug and investigate further, but let me bring up some points here first: * I suppose right now Evolution continues to use its own libical. Are there plans to synchronize with upstream (whathever that is at the moment)? Evolution-2.10 uses the libical from the stable branch. Evolution-2.12 would use the libical from svn HEAD. Evolution does not own a separate libical. * Any bug fix for this should be backwards compatible and treat \, just like a normal comma because all existing .ics files will continue to contain \, and I would like to add a hack to SyncEvolution which converts between \, and , to work around the issue in existing Evolution versions. The bug is in libical and any fix made there would be done so that its backward compatible. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Calendar Maintainership
On Thu, 2007-05-31 at 10:32 +, Srinivasa Ragavan wrote: Hi friends, It is with immense pleasure I announce that Christian Kellner joins Chenthill as Calendar Maintainer. He is popularly known as gicmo on IRC. Gicmo is already the maintainer of gnome-vfs. He is the author and the maintainer of evolution-scalix and the CalDAV provider for Evolution. Welcome on board Gicmo !!! Welcome Gicmo !!! I am happy to share my responsibilities with you. Let us discuss and capture our future plans in go-evolution.org. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Question about Groupwise and Memos (see bug 389668)
Hi nathan, I added the summary and start date fields looking at the supported fields for the VJOURNAL component. I have not observed the initial discussions which had happened in the e-hackers list. I feel its better to have a start field so that the notes can be sorted well and would be really useful to know when a note was created. The summary field can be made optional depending on the backend's needs. I really did not want to write another backend or a component for just supporting the summary field in addition to what the memos component intially supported. The UI changes can be probably taken up for evolution-2.12. thanks, Chenthill. On Sat, 2007-02-10 at 09:39 -0800, Nathan Owens wrote: Back when the Groupwise functionality was implement for the Memos component, the summary and start date fields were added to the Memos GUI. I was wondering why this is done. IMO, Memos shouldn't have a start date, or a summary. In fact, when I originally implemented the component, the Summary field was just a cut-off portion of the Description. It was done on-the-fly, and only because I wanted a portion of the Description to show up in the Memos component table view. Showing the Description field in the Memos component table didn't look very good. Adding the summary field has now caused this bug: http://bugzilla.gnome.org/show_bug.cgi?id=389668. As for the Start Date - the memos component isn't meant to be a Journal. It only uses the VJOURNAL format because I didn't want to write a new backend (and at the time, the consensus on the evolution-hackers list was that VJOURNAL would be appropriate). If we want a true journal, then we need a new component. Memos are just little notes (think of the Notes feature in Outlook, or the Memos feature in PalmOS - the PalmOS feature is what made me create the Memos component in the first place). Here's my proposal that I'd like to get feedback on: - Remove the Summary and Start Date fields from the GUI - Start Date is never set (could always be set to 0, but I don't believe I needed to do that when Memos was first implemented) - The summary field is automatically filled in (on-the-fly, or whenever the Description gets updated) based on the Description. I don't know much about GW, but I believe the core code should not support the Date and Summary fields as they are currently supported. If we need something different for GW, then it should be implemented differently. Any thoughts? Anyone have insight into the Groupwise changes and why they were made? Thanks, Nathan Owens Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather ___ 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] Recurrence ID?
Hi Jules, The format of the recurrence id (datetime value) is the same as that is specified in rfc 2445. thanks, Chenthill. On Fri, 2006-10-13 at 14:49 +0200, Jules Colding wrote: Hi, What is the format of the recurrence ID (const char *rid) as used in get_object(), remove_object() and other related calendar methods? Thanks, jules ___ 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] Converting vevent components into one vcalendar component
Hi teresa, You can probably create a toplevel VCALENDAR component using e_cal_util_new_top_level () and add the VEVENT components to it using icalcomponent_add_component. Hope this answers your question. - Chenthill. On Wed, 2006-08-09 at 15:44 -0400, Teresa Thomas wrote: I intend to use the function void icalcomponent_merge_component(icalcomponent* comp, icalcomponent* comp_to_merge); to merge two VCALENDAR components. When I query for all the objects in an Evo cal, what I get is a list of icalcomponent. I want to convert this bunch of VEVENT icalcomponents into a single VCALENDAR icalcomponent so that I can use the above mentioned function. Ofcourse, I could convert them into strings first and manually concatenate the objects, but is there a better way to do this? Thanks! Teresa ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Obtaining all events from Evo Cal
Hi Teresa, Send the query as #t. - Chenthill. On Tue, 2006-08-08 at 18:14 -0400, Teresa Thomas wrote: Hi How can I obtain all the events existing in an ECal. I tried using the function: gbooleane_cal_get_object_list ( ECal *ecal, const char *query, GList **objects, GError **error); with a and NULL as parameter for query, but it returns a 0 on both occassions. Thanks in advance! Teresa ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync
Hi peter, You would need to implement both. The ECalBackendSync class has a sync lock, which is used if the backend can handle only one operation at a time. It provides the results immediately to the caller. ECalBackend class provides notifications to the client from EDS. Please go through http://www.go-evolution.org/EDS_Architecture for more details. On Mon, 2006-07-31 at 03:08 -0400, Peter Colijn wrote: Suppose I am writing a new calendar backend. Which of these two interfaces is preferred? If I implement ECalBackendSync, will operations on the calendar cause the UI to block? It depends on how client is designed. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync
Are you writing a new backend similar to file/http/groupwise ? If so you can implement the virtual methods extending from ECalBackendSync class. You can prolly refer to any of the existing backends or evolution-exchange/calendar. thanks, Chenthill. On Mon, 2006-07-31 at 04:22 -0400, Peter Colijn wrote: Hi Chenthill, On 7/31/06, chenthill [EMAIL PROTECTED] wrote: You would need to implement both. The ECalBackendSync class has a sync lock, which is used if the backend can handle only one operation at a time. It provides the results immediately to the caller. ECalBackend class provides notifications to the client from EDS. Please go through http://www.go-evolution.org/EDS_Architecture for more details. On that page, it says To write a calendar/tasks backend, a subclass of ECalBackend (for asynchronous) _OR_ ECalBackendSync (for synchronous) needs to be written. (emphasis mine) If both need to be implemented, perhaps that article should be updated? I can see how I could implement EBackendSync, then implement EBackend on top of that by having a worker thread that calls the EBackendSync calls. Is that what you're referring to? It depends on how client is designed. Well, my intended client is Evolution :P With Evolution as the client, if I implement ECalBackendSync, will the UI block? Harish mentioned that I could avoid having the UI block if I had a separate thread for repainting. But if I'm just adding a new calendar backend, and I want to use it from Evolution, am I writing any code to do redrawing, etc? I certainly hope not! Thanks! Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ESourceGroup from ESource
On Wed, 2006-07-19 at 18:09 -0700, Scott Herscher wrote: How does one derive an ESourceGroup from an ESource? If I call e_source_peek_group() with a valid ESource instance, and then immediately call E_IS_SOURCE_GROUP(), I am getting false. Was the ESource got from ESourceList ? If so, ESourceList object should be alive while accessing the ESource, otherwise ESourceGroup would be NULL if the corresponding ESourceGroup was not ref'ed. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal functions
On Wed, 2006-07-19 at 11:25 -0400, Teresa Thomas wrote: Hi I have one last (hopefully) question about libecal. I want to add a VEVENT to an existing Evolution calendar. Hence, I created an iCalComponenent to be added and hope to use the e_cal_create_object(ECal* eCal,iCalComponent iCalcomp, char** uid, char** error) function. Now, I understand that eCal is a calendar client. If I want to add my event to an Evolution calendar, what exactly should eCal contain? Is it some sort of an identity of a cal? If so, how can I obtain it. ECal client can be obtained by using the function e_cal_new, by passing an ESource. ESource holds the settings required for a calendar client which is stored in gconf. The client is associated with the backend through the protocol specified in the uri stored in ESource. Eg: uri starting with file:/// would refer to file backend, contacts:// would be pointing to contacts backend. - Chenthill. Thanks! On 7/19/06, Teresa Thomas [EMAIL PROTECTED] wrote: Thanks Mr Palanisamy! My Bad, I actually meant to ask about the function e_cal_component_new() in ECalComponent.h/c. Anyway, from what I understand it returns an ECalComponent, which is an (easier to manipulate) wrapper around an iCalComponent. On 7/19/06, chenthill palanisamy [EMAIL PROTECTED] wrote: On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas wrote: Need some assistance in my quest to comprehend EDS. What exactly is the difference between e_cal_create_object() [in ECalComponent] and e_cal_create_object() [in ECal ] ? e_cal_create_object is used to create a appointment, task or a memo object (ECalComponent) in the corresponding backend (file, http, groupwise etc). There is no function named e_cal_create_object in ECalComponent. There is a function e_cal_component_get_created which gives the creation date of a ECalComponent. Please have a look at http://www.go-evolution.org/EDS_Architecture . - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal functions
On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas wrote: Need some assistance in my quest to comprehend EDS. What exactly is the difference between e_cal_create_object() [in ECalComponent] and e_cal_create_object() [in ECal ] ? e_cal_create_object is used to create a appointment, task or a memo object (ECalComponent) in the corresponding backend (file, http, groupwise etc). There is no function named e_cal_create_object in ECalComponent. There is a function e_cal_component_get_created which gives the creation date of a ECalComponent. Please have a look at http://www.go-evolution.org/EDS_Architecture . - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exposing Evo calendar events
On Sun, 2006-07-16 at 16:24 -0400, Teresa Thomas wrote: Thanks Andre, I have been looking at that EDS architecture details but it just gives a general picture. I am having starting troubles with EDS. Just so I can get started, does anyone have any sample code that exposes the events/tasks of an evo calendar? Have a look at the clock applet code which queries the events/tasks from EDS and shows it. http://cvs.gnome.org/viewcvs/gnome-panel/applets/clock/ or the alarm daemon which queries for the events that has alarms for the current day. http://cvs.gnome.org/viewcvs/evolution/calendar/gui/alarm-notify/ cheers, chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ECalComponentAttendee and ECalComponentOrganizer - an invitation to memory leaks?
Hi Jules, On Wed, 2006-06-07 at 14:41 +0200, Jules Colding wrote: Hi, Several members of the above mentioned structures are of the 'const char *' type. One such member is 'value'. The message from the API designer, when declaring something 'const char *', is commonly that the memory management of that parameter/member is the responsibility of whoever allocated the memory. Yes, the memory for the members such as value is managed inside the ECalComponent itself. The caller need not allocate the memory. The usage of ECalComponentAttendee and ECalComponentOrganizer data structures in e-d-s is, OTOH, that they are given to some ECalComponent and are never touched by the callee again (unless I am totally wrong here). So should data for e.g. the 'value' member be g_strdup'ed to 'value' (as does the Groupwise calendar backend) contrary to the expectation that the callee should manage the memory for that member? Groupwise backend does it wrongly which needs to be fixed. Thanks for pointing it out. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What 'role' should a resource-type cutype have?
Hi Jules, On Thu, 2006-06-08 at 13:15 +0200, Jules Colding wrote: Hi, I can't decide upon the ICAL role that a ECalComponentAttendee should have if cutype is a resource. I am currently doing: attendee-cutype = ICAL_CUTYPE_RESOURCE; attendee-role = ICAL_ROLE_NONPARTICIPANT; // what else? Is that the best thing to do? - Thoughts? yes, AFAIK the resource would be a non-participant. thanks, Chenthill. Thanks, jules ___ 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] When do open_sync() gets called from a calendar backend?
Hi Jules, Once the mode and timezone is set, e_cal_open_async would be called to open the calendar. Please check if e_cal_open_async is being called from evolution. You need not invoke it separately. thanks, Chenthill. On Fri, 2006-05-05 at 14:05 +0200, Jules Colding wrote: Hi, I am a bit mystified, due to my lack of intellectual resources, about the behavior of my calendar backend. I have created the gconf source for the calendar and are trying to get Evolution to call open_sync() on it, but that never happens. Instead I am seeing set_mode_sync() and set_default_timezone_sync() being invoked (in that order). The next thing to happen is that Evolution tells me that it is unable to open the calendar. Do I have to invoke open_sync() myself at some appropriate time? Thanks, jules BTW: I have invoked e_cal_backend_sync_set_lock(backend, TRUE) in e_cal_backend_brutus_init() to force serialization of method invocations. ___ 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
