[Evolution-hackers] GMail IMAP support in Evolution
Google seem to be in the process of introducing IMAP support to GMail [1]. Personally I think GMail offers an extremely attractive email solution by now. Evolution does already support integration with GMail via SMTP and POP, and now also via IMAP. In addition to following the IMAP standards as closely as possible, I think we should do explicit QA on Evolution-GMail IMAP integration, to make sure our users' experience is as good as possible. One of the slashdot comments has already commented that Outlook works better with GMail IMAP than Evolution. That should change! I've only used tested Evolution-GMail IMAP for a few minutes so far, but already found a minor issue: I'm not able to prevent sent mail from being stored. SMTP through GMail saves sent mails automatically. First of all, I'll recommend everyone to try out GMail IMAP, and then I hope some initiative will be taken to QA this integration. Cheers, Øystein [1] http://slashdot.org/article.pl?sid=07/10/24/0249257 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
2007/5/31, Ross Boylan [EMAIL PROTECTED]: On Thu, 2007-05-31 at 23:20 +0200, Øystein Gisnås wrote: 2007/5/31, Matthew Barnes [EMAIL PROTECTED]: On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote: What version to start with? I'm on Debian GNU/Linux, which currently has evo 2.6. I notice that's a bit dated (although I did see that a few months ago some of the Debian packagers were interested in making a more recent version). I've been working from the Debian version. Does that version, the last stable release (from evo, not Debian), or svn head make the most sense to work from? (BTW, the one bug I fixed was one that was already fixed post-2.6). FYI, Debian Unstable has Evolution 2.10. Might be easier to grab at least the 2.10 dependencies from there. You'll need to upgrade gtkhtml and likely also your GTK+ library stack to get 2.10 to build. In case you're on a Debian-based distribution Yes; straight Debian. and not pulling from svn, I would recommend using pre-built packages, or even building the packages yourself. 2.10.2 is in the archive, and I will do 2.11.2 this weekend. Terrific. Is unstable the place to look, or experimental, or somewhere else? 2.11.2 will end up in pkg-evolution's svn for sure. If we upload binary packages, they will go to experimental. For my own development setup I use the 2.10.x packages plus custom build from svn for the module I'm hacking on. e-d-s for example, I install to /opt/evolution-data-server. Then I can start development e-d-s with 'LD_LIBRARY_PATH=/opt/evolution-data-server/lib /opt/evolution-data-server/libexec/evolution-data-server-1.12' and can also start the stable e-d-s with '/usr/lib/evolution/evolution-data-server-1.10' That's a great tip. I built evo from Debian source (with one fix) and it took 45 minutes. I clearly need a shorter route to trying out changes. I don't think you get around the initial build; you can feature strip it to reduce the time. Once you've built it. make will figure out what has to be rebuilt. A make make install when I edit files in only one directory takes about 5 seconds on my system.. Thanks for packing evo, and for making the -dbg files available. You're welcome. Don't hesitate with questions on how you can use packages or package scripts in your development setup.. Cheers, Øystein ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Improved vCard parser
2007/5/30, Ross Burton [EMAIL PROTECTED]: On Wed, 2007-05-30 at 07:59 +0200, Øystein Gisnås wrote: I posted some lines about improvements to the vCard parser, but it seems like getting multi-megabyte attachments take some time to get through to the mailing list. So I posted to my blog instead: http://n800evolution.blogspot.com/2007/05/improved-vcard-parser.html Could you post the message itself, without any attachments? There are some point I'd like to make, but without the context of the original post it would be tricky to read. Sure: I'd like to focus on the vCard parser and export in libebook. Some things I've noticed: - v3.0 import is quite well supported, with the major exception of charsets http://bugzilla.gnome.org/240756 tracks all the v3.0 bugs - v2.1 import was well supported, but is gradually getting worse since there is a common codebase for 2.1 and 3.0, and most people care about 3.0 - v3.0 export is good, with minor exceptions (CRLF at end of card for example) - v2.1 export is non-existant - performance is important, as vCards are used in the file-backend. From a performance perspective, that's horrible, but it has its advantages too. For large vCards, the poor performance easily kneeled the system, for example with a medium sized photo. With http://bugzilla.gnome.org/433782 it got much better, but there's still a lot of potential for improvement I've created a patch (against svn trunk) that improves the performance of the parsing itself (only v3.0) and adds some other fixes like CRLF at the end of the card. The patch is supposed to be non-intrusive, and will not break public APIs, but mainly create new internal methods that will only kick in for vCards with VERSION:3.0 in the second line. Other vCards will be parsed as before. After the patch, I created a test suite (attached archive) to test my own patch and the current implementation. I used a different approach than Ross in eds-dbus (http://svn.o-hand.com/view/eds-dbus/trunk/addressbook/testsuite/). Instead of creating classic hand-coded unit tests, I compare a parsed file with a file that has the expected format. That way, new tests can be added with much less effort, without writing any code. The downside is that not all aspects of parsing can be tested. For example, if a list separated with comma was read as one chunk, it probably wouldn't detect that it should have been separated at the commas. Anyway, I think the test suite makes sense and can be supplemented by classic unit tests. Try it out and add more tests! To run the v3.0 tests, for example, add the .vcf's in vcard/valid-3.0 as parameters to src/test-vcard-suite. -e outputs detailed error messages and -r 100 will repeat the parsing 100 times for benchmarking. A typical command I use is: LD_LIBRARY_PATH=/opt/evolution-data-server/lib -e src/test-vcard-suite vcard/**/*.vcf A major weakness in the vCard 3.0 specification is its inability to tag vCards in files with charset. The only ideal solution, as I see it is to ask the user which charset he wants to use and maybe also display a preview. For vCards in emails (anything MIME), the charset can already be specified. What the parser needs is support for converting from the specified charset. I added an extension of the patch that does this too. It breaks the API and will need extensions to the UI to be of any practical value. For now, focus on the patch without charset support. Ross' patch at http://bugzilla.gnome.org/312581 is related, and efforts should ideally be joined. What we need is a strategy (Ross and Srini) of where to end up. I see three possible roads: - An optimised v3.0 parser with fallback to a quirk-mode parser for v2.1 and buggy v3.0 (my patch goes down this road) - One v2.1 and one v3.0 - One parser to rule them all, but has to be very, very clever to maintain high performance and at the same time support quoted-printable (basically what we have now, minus some performance) Independent of the choice of strategy, there are a couple of obvious spots to improve. * Export is quite streamlined, but the method doing escaping can be improved * Whenever e-d-s requires glib 2.12 anyway, maybe glib's base64 can be used for improved performance(?) and reduced code complexity/maintainability? That was a lot, but the gist is everyone, give some attention to the vCard parser - improve it, test it or add test cases for whatever doesn't work for you! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Upgrade path from 2.6 to 2.10
Are there any changes in the data format between 2.6 and 2.10.1? Or anything else that may cause trouble without installing 2.8 in between? We're considering to package 2.10.1 as a replacement for 2.6.3 in the Debian distributions. If there are any possible upgrade problems, we'd like to investigate that before the upload Cheers, Øystein ___ Evolution-hackers mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gtkhtml API version
2007/4/14, Matthew Barnes [EMAIL PROTECTED]: On Sat, 2007-04-14 at 16:51 +0200, Øystein Gisnås wrote: What happened to the gtkhtml API versioning before the GNOME 2.18 release? Seems like it was a mistake to do the bump in http://svn.gnome.org/viewcvs/gtkhtml/trunk/configure.in?r1=8408r2=8425 It is not the new strategy to bump API_VERSION for every release I hope..? As Tor Lillquist mentioned, it's to late to revert now. What will happen before the next release (given that API/ABI is not broken)? It's NOT desirable to let the API_VERSION follow the general version number! Bumping the API was not a mistake. It marked the migration from GnomePrint to GtkPrint, which broke GtkHtml's API. GtkHtml no longer depends on nor supports GnomePrint. The API_VERSION should only change when the API actually changes. Incrementing it to match the version number rather than by one was a policy decision, as I recall. Ok. That is perfectly fine then. As long as the policy is followed in prior releases... Øystein ___ Evolution-hackers mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libebook scalability
2007/4/2, Srinivasa Ragavan [EMAIL PROTECTED]: On Mon, 2007-04-02 at 01:12 +0200, Øystein Gisnås wrote: I discovered a bottleneck for addressbook performance with large addressbooks. Details at http://n800evolution.blogspot.com/2007/04/libebook-scalability.html Looks fine to commit. A proposed fix is attached. I'm not sure if order matters when returned from the backend? Does anyone know? If not, g_list_reverse can be omitted. Atleast here the order wont matter. Im sure that there are more such bottle necks. It will be nice task to take these up. Øystein? I'll look into this, but I can't fit it in very soon, so it's up to anyone to have a go.. I'd also love to create scripts, code and test data to test performance of some of the most important functions. Then we would be able to track performance over time in a more scientific way. Also, whether we're gonna use GQueues, GSLists, or reversed GLists is an interesting discussion. Does GNOME in general have any recommendations for that? Øystein ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libebook scalability
2007/4/2, Ross Burton [EMAIL PROTECTED]: On Mon, 2007-04-02 at 09:03 +0200, Øystein Gisnås wrote: I'd also love to create scripts, code and test data to test performance of some of the most important functions. Then we would be able to track performance over time in a more scientific way. http://burtonini.com/bzr/eds-tests/ Check that out with bzr and you get a few tools: 1) a dummy backend for libedata-book. Ask for a contact and you get the same one back. As for a contact list and you'll always get the same 10. Ask for a book view and (mwhaha) you'll get 10 contacts. This makes profiling the EDS infrastructure easier as the backend has almost zero overhead. I should probably reduce the number of contacts returned in a book view as malloc tends to swamp the profiles now. 2) eds-bookview. A test application that will open and repeatedly request book views for a given number of times and URL. For example: $ eds-bookview --uri dummy:/// --repetition 10 --silent Will visibly do nothing for a few minutes but EDS will be very busy. Attach a profiler and come back 10 minutes later to discover that EVCard parsing is still primary bottle neck in eds-dbus. Very useful.. And a first hands-on bzr for me.. It indeed seems like the vCard is a bottleneck here. One thing is the CPU cycles for parsing that add up a bit on small datasets. For larger datasets, the size of the vCard itself adds up a lot. My test with 1*10^6 contacts made a 350MB on the disk, plus a 100MB summary. The same data in MySQL resulted in a 10MB database. Øystein ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libebook scalability
I discovered a bottleneck for addressbook performance with large
addressbooks. Details at
http://n800evolution.blogspot.com/2007/04/libebook-scalability.html
A proposed fix is attached. I'm not sure if order matters when
returned from the backend? Does anyone know? If not, g_list_reverse
can be omitted.
Øystein
--- addressbook/backends/file/e-book-backend-file.c.orig 2007-04-02 00:42:20.871493559 +0200
+++ addressbook/backends/file/e-book-backend-file.c 2007-04-02 00:43:08.298457559 +0200
@@ -412,7 +412,7 @@
db_error = db-get (db, NULL, id_dbt, vcard_dbt, 0);
if (db_error == 0) {
-contact_list = g_list_append (contact_list, vcard_dbt.data);
+contact_list = g_list_prepend (contact_list, vcard_dbt.data);
} else {
g_warning (G_STRLOC : db-get failed with %d, db_error);
status = GNOME_Evolution_Addressbook_OtherError ;
@@ -451,7 +451,7 @@
|| strcmp (id_dbt.data, E_BOOK_BACKEND_FILE_VERSION_NAME)) {
if ((!search_needed) || (card_sexp != NULL e_book_backend_sexp_match_vcard (card_sexp, vcard_dbt.data))) {
- contact_list = g_list_append (contact_list, vcard_dbt.data);
+ contact_list = g_list_prepend (contact_list, vcard_dbt.data);
}
}
@@ -473,6 +473,7 @@
}
}
+ contact_list = g_list_reverse (contact_list);
*contacts = contact_list;
return status;
}
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Backport of fix to Too Many Open Files problem
2007/1/11, Matthew Barnes [EMAIL PROTECTED]: On Wed, 2007-01-10 at 23:26 +0100, Øystein Gisnås wrote: I see users on 2.6.3 struggle with the problem described at http://mail.gnome.org/archives/evolution-list/2006-October/msg00130.html http://bugzilla.gnome.org/show_bug.cgi?id=34 and http://bugzilla.gnome.org/show_bug.cgi?id=356913 I've looked at the patch (it's said to be fixed in 2.9.1). Looks like someone attempted a fix and it's been reverted and rewritten again. What's the correct patch for the problem. Does anyone have a gut feeling if it's good to backport that to 2.6.3? I wrote the patch. You have good timing because we discovered a critical flaw in the patch for bug #34 just today. I recommend applying the patch in bug #34, followed by the patch for bug #384183. I think it should be safe to backport to 2.6.3; it's a rewrite of some very old code. Note that it does break the ABI of libedataserver. Thanks. I did not mean 2.6.3, but 2.8.2.1. I'll test with those two patches against our reported incidents. Do you have any idea if this can happen in 2.6? If so, why has noone reported it yet? A pity with the ABI break. Makes things a lot more complicated to push. Øystein ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution
2006/10/15, Patrick Ohly [EMAIL PROTECTED]: * Is someone going to take care of the reported regression or do you need a patch to fix it? Whoever changed the code between 2.6 and 2.8 should be in a better position to fix it, so I am a bit reluctant to investigate further in code that I don't know. It seems like this is quiet times when it comes to patch review. I am very sure though, that a bug report with a good patch will much more likely be applied soon. If upstream doesn't look at it, I will consider applying it to Debian. * Is someone running Evolution and in particular the Evolution data server under valgrind as part of release testing or regular quality assurance? I know there is performance work in relation with evolution for suse installations. For general quality assurance there are not enough routines in place. I know it's on the todo list of the developers. When it comes to valgrind testing, evolution becomes quite slow so patience is a must. * Which branches are still maintained? At the moment Debian still has 2.6 in testing and unstable; if there is a chance to still get bug fixes into that version, I'd concentrate on that first instead of the more recent 2.8. There is still a chance to get bug fixes into 2.6. Right now I plan an upload of evolution-exchange 2.6.3, but there may be uploads of evo and e-d-s soon, depending of the severity of the problems. 2.8 is in experimental, and we still hope we can push that in before the release of etch. I would recommend developing against 2.8 actually, since your application isn't targeted for etch. /* Øystein Gisnås */ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libecal and libedata-cal versions
During the 2.6.x cycle, there were version bumps of libecal and libedata-cal to make up for a previous ABI break in these two libraries. It was unfortunate to bump the versions in a stable tree, but now I'm more interested in the 2.8.x release. When the version bump was commited to 2.6.x, it was not commited to the 2.7.x tree. Why was that? Because you only bump versions just before releases? I hope so. I noticed that libedata-cal versions were synced with 2.6.x in http://cvs.gnome.org/viewcvs/evolution-data-server/configure.in?r1=1.184r2=1.185. libecal was also bumped there, but AGE was not reset. Is the plan to reset AGE just before the final 2.8.0 release, or was it a mistake not to reset it before. The last thing we want is to release 2.8.0 with a lower SONAME version than 2.6.x.. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] addressbook-file plugin
As far as I can see, the addressbook-file plugin (aka local addressbook) fixes a grave bug causing data loss when address books are deleted. Is there a reason this fix is only implemented as a plugin? Even if the plugin is installed as default, what if users disable the plugin? If no-one has a some good reasoning for the current solution, I'll file a bug about it and start testing a patch. Cheers, Øystein Gisnås signature.asc Description: Dette er en digitalt signert meldingsdel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Request for adding version information to libcamel soname
The Debian Evolution Maintainer Team is planning the upload of Evolution 2.6 to unstable to happen very soon. Before the upload, we'd like feedback from Evolution developers on the biggest change we make to the upstream release. In specific, Harish confirmed bug #321372, which is what this is about, and also Parthasarathi probably have valuable comments on this topic. The first part of the change was described in the previous mail in this thread. In addition to using version numbers to libcamel (contrast to today's 0:0:0), we plan on moving the private libcamel provider libraries to an install location that is version specific. The current location is /usr/lib/evolution-data-server-1.2/camel-providers/, which includes the API version, but not libcamel version. As far as I know, it has already been discussed to name the e-d-s directory differently. Do you have an update on if/when that will happen? What we will do on the debian side is to move the contents of camel-providers to camel-providers/8, or alternatively name it camel-providers-8 or similar. We highly value having the same names and versions in our releases as in upstream. If you could give some indications on what changes will be made upstream, and what names and versions will be used for this, we could use that name/version scheme already and avoid future conflicts. Our release will not be delayed indefinitely, but we'll put effort into avoiding a diversion from upstream directions. Therefore a quick answer will be greatly appreciated. Thanks, -- Øystein Gisnås Debian Evolution Maintainer Team signature.asc Description: Dette er en digitalt signert meldingsdel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Request for adding version information to libcamel soname
Previously, Loïc Minier reported a problem in how the libcamel library is versioned, see http://bugzilla.gnome.org/show_bug.cgi?id=321372. The problem can be seen in the filename /usr/lib/libcamel-1.2.so.0.0.0, which stays the same between each release. For the distribution package maintainers, having possibly incompatible libraries with conflicting filenames is a headache. Regarding Evolution 2.6 for Debian, changing the soname would mean losing binary compatibility with other distributions. Although not ideal, that is currently being considered. What is important for us is to choose an soname that won't conflict with a potential future soname upstream. Therefore, we'd like to have your thoughts on if libcamel should have versioned soname or not, and what version scheme you will use. Our suggestion is that we use -version-info $(LIBCAMEL_CURRENT): $(LIBCAMEL_REVISION):$(LIBCAMEL_AGE) for 2.6 and upstream does the same for the next release with bumped versions. How does that sound? -- Øystein Gisnås Debian Evolution Maintainer Team signature.asc Description: Dette er en digitalt signert meldingsdel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
