Re: [Evolution-hackers] GMail IMAP support in Evolution
One thing you could do which would be of use would be to sniff the packets that Outlook sends to Google Mail's IMAP and log them for the Evolution developers to read so that perhaps they can see what queries Outlook is doing that is so much faster than what Evolution is doing and maybe try to mimic Outlook. I have a feeling, though, that the main reason Evo is so much slower than Outlook is due to the summary info gathering which (used to?) grab all the mailing-list headers as well as the normal stuff in order to be able to vfolder on mailing-list. Jeff On Wed, 2007-10-24 at 13:11 +0200, Øystein Gisnås wrote: > 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 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Memory leak question in CamelImapCommand
Hi there, t almost sounds impossible but still, and that's why I ask. I noticed that the variable "args" in imap_command_strdup_vprintf is never freed. That would be a rather large memory leak (almost every IMAP command is created this way). So I'm a bit stunned that nobody else ever saw this one and I wonder whether I'm just not looking very good, or being confused or something (this happens often to me, so it wouldn't surprise me). The patch is of course a simple "+ g_ptr_array_free (args, TRUE);" right before the "return out;", right? ps. Adding Jeffrey in CC as I think he has a good idea how this function should work. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leak question in CamelImapCommand
On Thu, 2007-10-25 at 16:45 +0200, Philip Van Hoof wrote: > Hi there, > > t almost sounds impossible but still, and that's why I ask. I noticed > that the variable "args" in imap_command_strdup_vprintf is never freed. > > That would be a rather large memory leak (almost every IMAP command is > created this way). > > So I'm a bit stunned that nobody else ever saw this one and I wonder > whether I'm just not looking very good, or being confused or something > (this happens often to me, so it wouldn't surprise me). > > The patch is of course a simple "+ g_ptr_array_free (args, TRUE);" right > before the "return out;", right? > > ps. Adding Jeffrey in CC as I think he has a good idea how this function > should work. Hi Philip, I actually fixed that a few months ago. http://bugzilla.gnome.org/show_bug.cgi?id=447753 Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Ubuntu 7.10 upgrade leaves useless libedataserver around
Hello, I think we have some Evolution packagers around here, so let me draw your attention to a problem that a SyncEvolution user recently had (see [1]). He upgraded to Ubuntu 7.10/Evolution 2.12, but still had a SyncEvolution binary around which depended on the older libedataserver1.2-7 from Evolution 2.10 (or 2.8). That library was not removed during the upgrade (not sure exactly why), which led to rather obscure error messages when starting SyncEvolution: (process:7164): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (process:7164): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (process:7164): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `ESourceGroup' (process:7164): e-data-server-CRITICAL **: e_source_group_peek_sources: assertion `E_IS_SOURCE_GROUP (group)' failed 21:07:48 GMT -0700 [ERROR] - calendar: not found: Cumples' IMHO it would be nice if the libedataserver1.2-9 packaged conflicted with libedataserver1.2-7 so that users who upgrade are notified that they need a SyncEvolution which is compatible with 2.12, either because their package manager knows that SyncEvolution depends on libedataserver1.2-7 or when SyncEvolution fails to start with a missing library error message. Note that I also ran into problems starting Evolution 2.6.3 after running Evolution 2.12 in the same account; I had to reset my gconf data to get 2.6.3 running again (more on that in another email) - I'm mentioning it here because it seems related. In case anyone is interested, because binary incompatibilities with Evolution releases require different SyncEvolution binaries I have gathered that information in [2]. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1818718&group_id=146288&atid=764733 [2] http://www.estamos.de/projects/SyncML/Compatibility.html#Evolution -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] New version of the Evo SVN Makefile - patch for Debian Etch
On Di, 2007-10-02 at 18:42 -0400, Paul Smith wrote: > Anyway, if you want a simple way to build Evo from SVN without > rebuilding all of Gnome (as with GARNOME), give it a whirl! > > http://mad-scientist.us/evolution.html Thanks a lot for this, I found it very useful. It did not quite do what I needed (building on Debian Etch), so I patched it (attached): * I don't need evolution-exchange and evolution-webcal, so I added the possibility to remove packages and enable flags from PACKAGES via local.mk: IGNORE_PACKAGES, IGNORE_FEATURES * Added package check for debian-etch, reusing the rules for Ubuntu: distro := debian-etch in local.mk * Etch's gtk+-2.0 and intltool are not recent enough for 2.12. I compiled them separately first and pointed with PKG_CONFIG_PATH, LD_LIBRARY_PATH (otherwise configure check for glib fails!) and PATH towards that installation (my local.mk is attached). The Makefile had to be changed to preserve these values. * I don't have root priviliges on the SyncEvolution nightly test machine, so I needed a way to disable sudo. * Added "export BONOBO_ACTIVATION_PATH=$prefix/lib/bonobo/servers" to evolution-svn to pick the right components for 2.12.1 * gnome-doc-utils was needed. I suspect it also needs to be added to ubuntu-PREREQS. I have successfully built Evolution 2.12.1 with these modifications on my desktop and without root priviliges on the SyncEvolution nightly test machine. One big warning! After starting Evolution 2.12.1 once and (after killing all of its processes) restarting Evolution 2.6.3 from Debian Etch the latter crashed reproducibly with: (evolution-2.6:19361): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (evolution-2.6:19361): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (evolution-2.6:19361): GLib-GObject-WARNING **: invalid uninstantiatable type `' in cast to `ESourceGroup' (evolution-2.6:19361): e-data-server-CRITICAL **: e_source_group_peek_name: assertion `E_IS_SOURCE_GROUP (group)' failed After restoring .gconf and .gconfd from a backup (= kill gconfd, copy whole directory hierarchy) it worked again. I did not investigate in more detail, but I saw that 2.12.1 had modified the source definitions in .gconf/%gconf-tree.xml. So unless precautions are taken, updating from 2.6.3 to 2.12.1 is a one-way street! -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ CCACHE := SUDO := true prefix := /usr/local/evo-svn distro := debian-etch V := branch := 2.20 IGNORE_PACKAGES := evolution-exchange evolution-webcal IGNORE_FEATURES := --enable-exchange=yes PKG_CONFIG_PATH := /home/patrick/evo-svn/gtk+2.0/lib/pkgconfig:$(PKG_CONFIG_PATH) export PKG_CONFIG_PATH PATH := /home/patrick/evo-svn/gtk+2.0/bin:$(PATH) LD_LIBRARY_PATH := /home/patrick/evo-svn/gtk+2.0/lib:$(LD_LIBRARY_PATH) export LD_LIBRARY_PATH *** /scratch/evo-src/Makefile.orig 2007-10-03 00:23:39.0 +0200 --- Makefile 2007-10-25 19:00:20.0 +0200 *** *** 58,66 --- 58,81 # Comment this out if you don't want to use ccache CCACHE := ccache + # Set this to "true" if you have to build without root priviliges. + # Beware that file locking of a local mailbox file may be affected! + # Installing without root priviliges is not recommended if you + # get email from a local file. + # SUDO := true + SUDO := sudo + # Set this to empty if you want to see the rules being run V := @ + # Optional packages which are not to be built, e.g.: + # IGNORE_PACKAGES := evolution-exchange evolution-webcal + IGNORE_PACKAGES := + + # Optional features which are not to be enabled, e.g.: + # IGNORE_FEATURES := --enable-exchange=yes + IGNORE_FEATURES := + # You can override the above by creating local.mk setting these vars # if you don't want to modify this makefile. *** *** 76,92 # These are the prerequisite packages needed on the system before we can build # Evo. There are different ways to check for them, based on distro. ! DISTROS := ubuntu ubuntu-PREREQS := \ gtk-doc-tools subversion libldap2-dev libnss-dev libnspr-dev \ libgail-dev flex bison build-essential evolution-dev \ icon-naming-utils $(CCACHE) # These are the packages we need to build from SVN, and any config/make/etc. # customized options we need to provide. ! PACKAGES := libsoup gtkhtml gnome-icon-theme evolution-data-server \ ! evolution evolution-exchange evolution-webcal CONFIG_VARS = CC='$(CC)' CFLAGS=-g CONFIG_OPTS = --prefix='$(prefix)' --- 91,114 # These are the prerequisite packages needed on the system before we can build # Evo. There are different ways to check for them, based on distro. ! DISTROS := ubuntu debian-etch ubuntu-PREREQS := \ gtk-doc-tools subversion libldap2-dev libnss-dev libns
Re: [Evolution-hackers] GMail IMAP support in Evolution
On Wed, 2007-10-24 at 17:01 +0530, Srinivasa Ragavan wrote: > Hi Øystein > > On Wed, 2007-10-24 at 13:11 +0200, Øystein Gisnås wrote: > > 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 agree here. I think we (Evolution team, although I'm not part of that, strictly speaking) should put a lot more effort in getting the best out of the latest IMAP standards. A lot of IMAP servers are also improving a lot lately, and are implementing these newer things. CONDSTORE, QRESYNC, IDLE, NOTIFY are samples of very interesting IMAP enhancements that we should support in my opinion. I also think that taking a look at spruce and GMime is a good idea for this. Although improving Camel's IMAP4 provider is not a bad idea either. The current Camel IMAP provider is limited in what we can make it do. I would, for example, love to have a solid client-side library that does pipelining with the IMAP server. Marrying the MIME handling with the server, for things like CATENATE, is also something I would love to have. Oh ... I have a lot of ideas :) > 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! > > It will change with 2.22. We are bringing down nice things down from > camel-lite to upstream camel and also doing nice things here as well. Note that I will attend a Lemonade meeting in Munich next month. If there are any items that I should raise for Evolution, you can let me know about them. I of course have a small list myself already. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory leak question in CamelImapCommand
On Thu, 2007-10-25 at 11:02 -0400, Matthew Barnes wrote: > On Thu, 2007-10-25 at 16:45 +0200, Philip Van Hoof wrote: > > > > The patch is of course a simple "+ g_ptr_array_free (args, TRUE);" right > > before the "return out;", right? > > > > ps. Adding Jeffrey in CC as I think he has a good idea how this function > > should work. > > Hi Philip, > > I actually fixed that a few months ago. > > http://bugzilla.gnome.org/show_bug.cgi?id=447753 > Oh, strange. Must have been a merge problem of last week then ... Ok well, then I guess we both saw this :). Good. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Let the porting begin
On Fri, 2007-10-26 at 03:25 +0200, Philip Van Hoof wrote: > On Wed, 2007-10-24 at 11:58 -0400, Jeffrey Stedfast wrote: > > I took a look at the IDLE implementation last night and felt it went > > about it the wrong way. > > Yes, you are right. I think the right fix is to create a new API called > camel_tcp_stream_wait that works like this: > > > int bytes = camel_tcp_stream_wait (tcp_stream, stop_fd, >store->idle_sleep, line_buffer, 1023); [snip] I was thinking more along the lines of making the idle_loop use PRPoll()/poll() itself - it already has to figure out what type of fd to create for the cancel_idle_fd anyway. > > Afaics It's not true that you don't need to change any API: > > The camel_stream_read() will block until all n bytes are read. no it doesn't. it returns as soon as any number of bytes are read or an error occurs. > This is > something you don't know during IDLE (how many bytes you can expect to > receive), and on top of that you want to continue immediately after > select returns, not keep retrying until you have n bytes (to simulate a > blocking read). sure, but that's why you poll yourself. once the socket has data, /then/ you call camel_stream_read() on it. > You also want a dedicated stop fildescriptor, not the > standard cancel_fd as then any cancel will interfere with this (while > you want strict control over this to let other threads start and stop > IDLE). right, but if you add a CamelStream API, then you have to add 1 for unix fds and 1 for PRFileDesc plus it keeps the code simpler (keeps all read() logic in the camel_stream_read() implementations rather than duplicating it). This actually brings me to another thought I've had for a few years now but haven't bothered pushing for it... but it might be best if all of the sockets used PRFileDesc rather than unix fd for raw sockets and PRFileDesc for SSL sockets. If this is done, I think it'd be possible to get rid of CamelTcpStreamRaw and move the implementation into CamelTcpStream and make CamelTcpStreamSSL a simple subclass of CamelTcpStream, replacing the CamelTcpStream's PRFileDesc with an SSL-wrapped fd as appropriate and calling parent_class->read/write/etc instead of implementing them all itself /again/. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GMail IMAP support in Evolution
On Thu, 2007-10-25 at 10:13 -0400, Jeffrey Stedfast wrote: > I have a feeling, though, that the main reason Evo is so much slower > than Outlook is due to the summary info gathering which (used to?) > grab > all the mailing-list headers as well as the normal stuff in order to > be > able to vfolder on mailing-list. I have made this as a configurable option and if the user does not want to fetch mailing-list headers he can choose to. (Though the default is that it will fetch) However, I am doubtful though how many users will be aware of what a mailing-list header is. > -- Sankar P Harver's Law: A drunken man's words are a sober man's thoughts Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
