[Evolution-hackers] Very poor performance and hangs with ema addressbook factory

2011-03-16 Thread sean finney
Hi all, First off, a quick into for those who haven't already met me in IRC: I'm consulting with the IT department of a large corporation who are evaluating evolution-mapi as a basis for a native linux mail client for use in large scale deployment. In the past month or two I've been hanging ou

Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches

2011-04-07 Thread sean finney
Hi David, On Thu, Apr 07, 2011 at 11:33:22AM +0100, David Woodhouse wrote: > Once this passes muster, I'll push these patches (probably *without* the > NTLM bits, if you're looking closely at what I included) to the > gnome-2-32 branches and perhaps start doing a 'final call' for 2.32.3 > candidat

Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches

2011-04-08 Thread sean finney
Hi David, On Thu, Apr 07, 2011 at 01:07:38PM +0100, David Woodhouse wrote: > Personally, no. I'd rather ignore MAPI completely and get on with the > implementation of evolution-ews. Understandable, though as we've discussed on IRC we don't really have the option of using that here, at least for a

Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches

2011-04-08 Thread sean finney
Hi David, On Fri, Apr 08, 2011 at 09:08:28AM +0100, David Woodhouse wrote: > You're more than welcome to use git.infradead.org if you want. But even > if Milan sees the 2.32 branch as being dead and doesn't want to spend > any of his own time on it (and nobody can blame him for that), I would > ho

[Evolution-hackers] EBookBackendSqliteDB comments

2011-05-04 Thread sean finney
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 f

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread sean finney
Hi! On Thu, May 05, 2011 at 11:20:45AM +0530, Chenthill wrote: > > * 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 str

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-05 Thread sean finney
On Thu, May 05, 2011 at 12:23:01PM +0530, Chenthill wrote: > > Be sure that parsing bdata is a pain, and always will, > > especially when you already are in a database world, where are tables > > and relations between them pretty common and nature. > This is the reason I was thinking whether it wou

Re: [Evolution-hackers] EBookBackendSqliteDB comments

2011-05-06 Thread sean finney
Hi Milan, On Fri, May 06, 2011 at 08:56:10AM +0200, Milan Crha wrote: > > 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 > > c

Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)

2011-05-13 Thread sean finney
On Fri, May 13, 2011 at 03:44:08PM +0200, Patrick Ohly wrote: > I tried the LD_PRELOAD=libeatmydata.so workaround suggested in the mail > above and it does avoid the problem. If eatmydata removes the bottleneck, then it's likely that either (a) each operation is corresponding to an fsync/fsyncdata