[Evolution-hackers] camel-db-summary changes merged to Trunk
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
Re: [Evolution-hackers] Unauthorised licence change to e-spinner.[ch]
Hi Christian, On Fri, 2008-09-05 at 15:16 +0200, Christian Persch wrote: Hi; The commit [http://svn.gnome.org/viewvc/evolution?limit_changes=0view=revisionrevision=36116] introduced a new copyright header for evolution/widgets/misc/e-spinner.[ch] [http://svn.gnome.org/viewvc/evolution/trunk/widgets/misc/e-spinner.c?limit_changes=0r1=36116r2=36115pathrev=36116] above the old copyright header, in which it claims the code is a) now licensed under LGPL 2 and LGPL 3, and b) now Copyright (C) 1999-2008 Novell, Inc. (www.novell.com). Both of these claims are false. e-spinner.[ch] is derived from ephy-spinner.[ch] from Epiphany, and I hold the copyright on much of the code in it. It is licensed under the terms of the GPL 2+. As you can see from e-spinner.c's svn history [http://svn.gnome.org/viewvc/evolution/trunk/widgets/misc/e-spinner.c?view=log], this file was first checked into evolution in 2007, at which time it was almost identical to ephy-spinner except for the rename of the namespace from ephy to e. See the attached diff from ephy-spinner to today's e-spinner after reversal of that rename to observe that the cumulative changes are trivial (not to mention partially bogus), and even if they might justify a 2007-2008 novell copyright they certainly do not justify putting the novell copyright notice above all other copyright holders and to even put a claim to be an Author of it! Most importantly, I was not asked for permission to re-license this code to the LGPL 2 + LGPL 3; nor have I given such permission. As there are many committers in Evolution sources, we sent out a common mail to the desktop-devel and evolution-hackers mailing lists. Please refer : http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00065.html Also, I have been blogging about the license changes in planet gnome as well, every time I make a change. http://psankar.blogspot.com/ Please revert this unauthorised license change immediately. I request you to wait till wednesday (10th September) , within which I will be able to do some analysis and get back to you. We will revert to the old state, if we cannot resolve the issue by then. Christian ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Does evolution source still contains GPLv2 code?
Hi, On Fri, 2008-10-17 at 11:21 +0800, Harry Lu wrote: Srini, So in current state, Evolution is still combined by GPL and LGPLv2/LGPLv3 code, right? The target is LGPLv3/LGPLv3 only, isn't it? We have not completed the license change for all the files yet and hence we had the COPYING file for all the three licenses. The code was earlier in GPL. We are in the process of changing every file in evolution to LGPL v2 / LGPL V3 Thanks. Thanks, Harry On Fri, 2008-10-17 at 08:42 +0530, Srinivasa Ragavan wrote: Jeff, The COPYING (GPLv2) old license, COPYING.LGPLv2 COPYING.LGPLv3 are present in the tarballs. Evolution still has some files left not moved to LGPLv2/LGPLv3. NEWs files might have been saying that some license changes code went in. Sorry for the confusion. -Srini. On Fri, 2008-10-17 at 11:01 +0800, Jeff Cai wrote: Hi From the 2.24 tar package and svn trunk, I can still find the COPYING file which says that it is GNU GENERAL PUBLIC LICENSE v2. But from NEWS, it says Evolution source code license changed to LGPLv2 LGPLV3 (Sankar P). Sankar, I'm curious about whether evolution still contains GPLv2 code. Jeff ___ 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 -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
On Mon, 2008-12-08 at 18:59 +0100, Philip Van Hoof wrote: All metadata engines are nowadays working on a method to let them get their metadata fed by external applications. Such APIs come down to storing RDF triples. A RDF triple comes down to a URI, a property and a value. For example (in Turtle format, which is SparQL's inline format and the typical w3's RDF storage format): We'd like to make an Evolution plugin that does this for Tracker. Obviously would it be as easy as letting software like Beagle become an implementer of prox's InsertRDFTriples to start supporting Beagle with the same code and Evolution plugin, this way. I just don't know which EPlugin hooks I should use. Iterating all accounts and foreach account all folders and foreach folder all CamelMessageInfo instances is trivial and I know how to do this. What I don't know is what reliable hooks are for: * Application started org.gnome.evolution.shell.events:1.0 - es-event.c - sample plugin: groupwise-account-setup/org-gnome-gw-account-setup.eplug.xml * Account added org.gnome.evolution.mail.config:1.0 sample plugin: groupwise-account-setup/org-gnome-gw-account-setup.eplug.xml For account-added: id = org.gnome.evolution.mail.config.accountDruid For account-edited: id = org.gnome.evolution.mail.config.accountEditor * Account removed You may have to write a new hook * Folder created * Folder deleted * Folder moved * Message deleted (expunged) * Message flagged for removal * Message flagged as Read and as Unread * Message flagged (generic) * Message moved (ie. deleted + created) * New message received * Full message * Just the ENVELOPE If you try to update your metadata for every of the above operations, it may be a overkill in terms of performance (and I believe more disk access as well for updating your metadata store). You can add a new hook while any change is made to the summary DB and listen to that. All the above changes will have to eventually come to summary DB for them to be valid. However, I personally believe: More and more applications are using sqlite (firefox and evolution my two most used apps.) So, it may be a better idea to directly map the tables in an sqlite database into the search applications' data-store (beagle, tracker etc.) instead of depending on the applications to give the up-to-date data. When we implemented on-disk-summary for evolution summaries, we removed the meta-summary code (used by beagle). We had to provide a way for helping Beagle / Tracker to know of modified/new mails, so they could (re)index these mails. Some suggested that we should add a DATETIME field which contains the time-stamp of the time last modified/created for each record. However, this in addition to bloating the database, also does not provide any information about deleted records. If, inside the sqlite db, if we have a special table comprising: table-name,primary keys of records of last N records modified/added,time-added; Any search application can make use of this and update its lucene (or whatever) data , It may not be the neatest approach, but what I want to say is : Instead of depending on the enduser applications (which use sqlite) for giving data, search applications, should be able to get the data from the db itself. This also provides additional benefits like creating/updating search indices when the machine is idle, instead of choking the applications when they are running, etc. My 0.2 EUROes ;-) -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reviewing imap_update_summary
On Sun, 2006-10-22 at 15:41 +0200, Philip Van Hoof wrote: Greetings, imap_update_summary is implemented in three or four steps: o. Getting (all) the headers/uids o. Finding the ones that we must still fetch o. Fetching those (x) o. Writing out the summary The steps each consume memory and reuse some of the memory of the previous step. Pointers to that memory is stored in GPtrArray's like fetch_data and messages. In the code I have found no real reason to why this was done in separated loops (steps) rather than one step and at the end of the loop, free the data already. Especially for the third step (x), which seem to consume most memory while it's happening. I rewrote this behavior in camel-GroupWise to fetch data in iterations, so that the memory requirement remains a constant k instead of O(n), n being the number of messages. I expected it work better. (GW and IMAP code are similar in this aspect) However, when I tested it, as expected, the memory requirement came down but the number of disk-access increased and hence it became slow. So I reverted it to the old behavior. You can try rewriting this in IMAP and you will find out that the time taken to complete the sync will increase in case of large folders. The current implementation requires the data being received from the IMAP service to be kept in memory until the entire folder has been received and all steps done. This consumes more than one entire kilobyte per message. Multiply that with for example 5,000 headers and you'll get 5 MB memory consumption for fetching the new messages of a very small IMAP folder (in case no other messages had been received before you first started the procedure). Multiply that with 50,000 headers and you'll get 50 - 60 MB memory consumption for a not extremely big but relatively big IMAP folders. Which will be freed, yes, but nevertheless it's a slowly growing peak (the speed depends on the connection with your IMAP server) that only gets deallocated or when pressing cancel or when all messages are received (which can take a significant amount of time). I tested the changes that I made (in camel-GW) and found that in actual deployment scenario, people prefer having an occasional memory-shootup (which will come down as soon as mail-fetch is complete) rather than having so many disk-access, that will eventually make operations longer to complete. The strange part is that if I measure the amount of bytes that I receive from the IMAP service; I measure far less bytes being transferred than bytes being consumed in memory. It not only stores all the received data, it also stores a lot more in memory (probably mostly 4 bytes pointers and GData stuff). I wonder whether there was a reason why it was implemented this way? If not, I'm planning to rewrite imap_update_summary in a different way. For example by immediately creating a CamelMessageInfo struct or burning it to the summary file instantly and freeing the GData created from the stream in-loop. If you want the memory usage to be a constant value, the best solution is to make the folder_sync function fetch summaries iteratively from a database back-end (not from flat-files or mmap). Perhaps this should be done at a higher (camel) level so that all the providers can make use of it; Means rewriting parts of the camel folder, summary etc. Anyway, all this is already covered under On-Disk-Summaries. If you are so obsessed about memory usage, go ahead and give it a try. Some times, the customer's needs are different from what the hacker may perceive to be the most important thing. Evolution's periodic memory shootup (and subsequent coming down) is considered to be normal by the customers than things like Proxy-authentication-failure (libsoup), EDS crashes etc, that we have been working on. It is an interesting work but we (the Evolution team) have got other priorities driven based on actual customer deployment needs. These are the most important things that Evolution (and indirectly Camel also) should address to become a stable enterprise-level GNOME app. Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Thu, 2007-02-15 at 23:22 +0100, guenther wrote:
On Tue, 2007-02-13 at 21:05 +0530, Sankar P wrote:
On Fri, 2007-01-26 at 16:59 -0600, Matthew Martin wrote:
I need to know where to put all
the UI items for templates. There would need to be a save template,
default new mail, and default reply items. I read some of the HIG and
stuck them in there so I could write the code. Here's a link to the
patches. http://mtt.martin.googlepages.com/ The first one is for
evolution, and the second is for evolution-data-server.
I had a look at the patch in the above url and some things that I found
on an first-look are:
The Template should be singleton and each account may not have a
separate template folder. (Should be like Outbox)
I'm not sure I agree here.
Still pondering, but... We offer per account Drafts folders. And I don't
yet see, why either one should be limited to a single, particular
machine in a, say, IMAP environment. Sent is not. Drafts is not. Why
should Templates be?
Based on this approach, I believe it actually should be per account,
being configurable exactly like the other default folders. Also, this
UI part should go there.
After all, Templates are Drafts that do not delete them selves, right?
Whatever we store under Templates are not completely formed messages.
They will not have any sender/recipient that a basic mail will have.
Also it will contain things like ${DATE}, ${me},
Reference-to-a-SIGNATURE-FILE, which takes some special interpretation
that is specific to Evolution alone.
Overall, it is just Evolution that can make meaning out of a thing that
is stored as a template in Evolution. It may not be of any use to other
mail clients. So, I do not see any benefit by putting it in the server.
It is more like Signatures that are specific to Evolution and are stored
locally in Evolution.
What will be really useful will be to have Names for these templates and
we can associate a default template for an account (Again like
signatures). These names can be used to choose, from New from Template
dialog as well; Like OO templates-choosing dialog.
guenther
--
Sankar
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
If all you need is just a non-deleting draft, you can use Edit as new message. I have felt that this shouldn't be restricted to Sent-items alone as we allow configurable sent-folders. IIRC, there is a bug for this as well. Srini: Shall we make this available on all folders ? -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Thu, 2007-02-22 at 13:32 +0530, Srinivasa Ragavan wrote: On Thu, 2007-02-22 at 00:38 -0700, Sankar P wrote: If all you need is just a non-deleting draft, you can use Edit as new message. I have felt that this shouldn't be restricted to Sent-items alone as we allow configurable sent-folders. IIRC, there is a bug for this as well. Srini: Shall we make this available on all folders ? Im not for this feature against templates. I feel that templates should be treated seperately. But I feel that this menu item should be enabled for all folder, unless it breaks mail abstraction if any. I am not sure if my previous mail made it clear. I am not against implementation of templates. All I wanted to say was: When you need just a non-deleting draft you can use Edit as new message as one. It is in the same way how we suggested people to use vFolders before we came up with the account-level search. Implementation of templates is a separate task that should be carried out independent of the status of this. -Srini -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Wed, 2007-02-21 at 12:15 -0600, Matthew Martin wrote: On 2/16/07, Sankar P [EMAIL PROTECTED] wrote: On Fri, 2007-01-26 at 16:59 -0600, Matthew Martin wrote: I'm working on templates for evolution. I need to know where to put all the UI items for templates. There would need to be a save template, default new mail, and default reply items. I read some of the HIG and stuck them in there so I could write the code. Here's a link to the patches. http://mtt.martin.googlepages.com/ The first one is for evolution, and the second is for evolution-data-server. I looked at the patches attached in the above url. The patches are not yet complete so I am not doing an in-line patch-analysis reply. Some of my comments are : - An account should be able to choose, what should be the default template that it has to use and it should be noted that NONE should also be an option here. Where should this be added? Isn't this what the Default New Mail thing is for? Do we even need the default new mail? How useful would that be anyway? - You can add an option, File-New from templates which should list the templates and the user should be able to choose a template and start composing a mail. I will recommend getting a nod from Srini (CCed) for any usability/UI aspects regarding this, before you start coding. - You need to add a view-column, Template name that will be available for the Templates folder (only). All messages stored as templates should have a name associated to identify the message-template. It is far more usable to read, Status Report, Release Announcement Mail, String Announcement Mail, ABI Break announcement ;-) etc., rather than opening every mail and seeing, Is this what I want to send now ? Shouldn't this act just like drafts? Where are we going to get this template name? Would this even be all that useful? It will be. On a longer run, we are planning to have pre-defined templates as well. A name for a template is always more useful than looking at the mail and knowing. Some people do not even enable Message-Preview. And think how useful a name for the template will be. Consider the scenario when a new employee joins an office and the moment he opens his Evolution, he can send things like Minutes-of-the-meeting, Status-report, Meeting-agenda, Leave-letters in the company-prescribed format. These standard templates will be pushed to his machine when the machine was prepared for him. You can ask for the name of the template once the user chooses, Save as template. - You need to close the composer once an user chooses Save Template (as of now it is not doing and it keeps on creating new templates) . Why should it do that? Saving a draft doesn't do this. Wouldn't this just annoy the user? It shouldnt close. Your code creates a new copy of the template whenever save is pressed. That also shouldnt be the behavior. - Reopening a template and saving it again should not create a new template. As explained above. - Your patch misses mail.error.xml changes as a result none of the user choice-asking dialogs appear. - All mail operations like copy/move/DnD on templates folder should be disabled. (IMO, it is a lot more easier to implement a new tab under Composer-preferences than a new templates folder) - When there is a clash between account's default signature and the used template's signature, the template's signature should be given more priority. - The code to save a template should ensure teh uniqueness in naming etc. - There must be a way to create a normal new mail when the user has set a default-template. (May be a default Empty-mail template) This isn't clear enough. How should this be done? Should the whole default new mail idea be rethought? Should we just make this like a draft that doesn't delete itself? What I am saying is: We may not want the same default new-mail template for all the accounts. It should be chooseable per account. My office account may need to have my company-logo, header, caption for all the mails that I send using it. Whereas, my personal account may want to default to a plain-text mail. And when the templates have a common storage that is not associated with any account, it will be useable across the accounts. Like the ANNOUNCE mail template that I described in my other mail. And to send a mail with in a defined template, just click on teh template, and choose new-mail-from-this-template from a contextual menu and/or file-new-mail-from-template which will list the templates. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
Gilles Dartiguelongue [EMAIL PROTECTED] 04/27/07 1:37 PM Le dimanche 08 avril 2007 à 23:11 +0200, Gilles Dartiguelongue a écrit : Hi list, in the process of enhancing plugins, I was looking for a mean to add an icon in the top level menus. After some code reading it seems it is not possible if the icon is not a gtk stock icon. Did I miss something ? Any pointers would be appreciated. At the moment, there is no direct way of doing it; as bonobo_main (ui) is called after the plugins are loaded. -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing Icons
On Wed, 2007-06-06 at 02:01 -0600, Jeshua Lacock wrote: Greetings, I managed to get evolution 2.10.0 mostly working on Mac OS X. Congrats. Once you are done with the build try to make an installer so that everyone can use. Note that here on Mac OS X I had to build libevolution-mail.so and libevolution-calendar.so as a dynamic library (.dylib) file instead of shared object (.so) to get things linked. The .so objects are also needed, but I had to create .dylibs for LD to be happy. Generally Mac OS X does not like linking to a .so... But, I now have missing icons, and no errors are being reported regarding the missing icons. In previous build attempts, I was also missing icons and a was getting an error about hicolor not being located (I no longer have the exact message, and I determined that there was a problem with my libpixbufloader). I then rebuilt my entire GNOME/GTK and now I do not get any errors, but to my surprise the icons are still missing. Note that Gnumeric (1.6.3) built on the same GNOME/GTK build does not have any missing icons, and appears normal. oh, Wait! I faced this while I built evo on mac. Try setting XDG_DATA_DIRS to your share folder. It should solve the issue. Also, check if you have installed your hicolor or some theme. If you launch gnome-theme-manager once and then start Evolution it should show all the icons. Can anyone offer a suggestion/hint? I certainly would appreciate it. Here is a screenshot of Evolution: http://OpenOSX.com/evolution.png Thanks, Jeshua Lacock, Owner http://OpenOSX.com phone: 877.240.1364 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar 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
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote: On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote: Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit : Without immediately writing to disk work, the download by itself will consume around 120 MB of RAM, and will most likely fail due to network timeouts and other such problems (it'll take a while, since Evolution fetches a ridiculous large amount of headers for each message for building its summary). isn't the imap-features plugin's goal to reduce/customize the amount of downloaded headers ? Or is it that it's still not enough ? It improves the situation by setting your url-string to have the basic_headers option. In the imap code of Camel, it will then ask for less headers (but still way too much). May be way too much for a mobile client; but not for a desktop email client. Sure you dont want your desktop mail client to have threading or show mail-size or have such basic things ? A major improvement it certainly isn't. Try comparing the performance of fetching all headers and basic_headers only. Some crude data which I collected a year back is at http://psankar.blogspot.com/2006/05/imap-performance.html The best way is to ask for the ENVELOPE and the remaining info using the normal BODY.PEEK method. It should be possible to specify per folder which of the headers are to be fetched, to make it really efficient. Do you really think any user on earth will really be interested in configuring what headers to fetch on a folder-basis ? The imap4 implementation seems to have an ENVELOPE parser, so I guess either it does it already or it will use ENVELOPE in future. For a mobile device, that works over GPRS, you for example are usually not interested (not at all) in the mailinglist specific headers. None of the mailing list headers will be fetched if you have chosen the basic_headers option. It would also be possible to do it in multiple passes. For example get a modest list of headers, and after that get more and more. In any case, none of the current Evolution code implements consuming the CONDSTORE capabilities of some modern IMAP servers (like MBox and Cyrus). CONDSTORE is really going to make an enormous difference in bandwidth consumption with large folders. That's because you only need to fetch the flags of the changed messages to synchronise flags. Note that Tinymail's camel-lite implements all the needed solutions to this bandwidth consumption problem. And that its code is, although a lot of work because the Evolution maintainers didn't seem interested at the time it was happening, definitely portable to upstream. Its implementation include solutions for the headers, it immediately saves the headers to disk and unlike Evolution's Camel it can resume partial summary downloads, it wont peek memory allocation during downloading, it implements Push E-mail using IMAP IDLE and it implements CONDSTORE. Although I'm definitely not satisfied with any of either Camel nor camel-lite's IMAP code. The thing is that I'd much prefer a client-side implementation that does proper pipelining. For example Infotrope, Telomer and Polymer does this on an experimental basis (Infotrope is the library). ps. In my opinion is also the imap4 project getting the majority of its design wrong. Although it looks better than the imap one, it's not the best way to use an IMAP server. If a project is going to write an IMAP client implementation 'today': they better do it right. A lot is changing in IMAP today (Lemonade, MORG, etc). It's important to get it right this time (the vast majority of E-mail clients totally suck at how they use the IMAP server, including Evolution indeed). Such a sweeping generalization !? As you mentioned, IMAP (like any other technology) grows at a very high-speed. What you consider as the right client implementation today may become obsolete tomorrow. When the initial IMAP provider was written there may not be a standard spec. for the PUSH/IDLE etc. No application can have an intelligent design that will remain forever satisfying all new needs/changes. Application designs should just evolve, adapting to the new changes. IIRC, you had a branch on Evolution's Camel to work on whatever changes you wanted to make, so that you don't have to wait for the delay due to review/maintainer. Would love to see some of the improvements that you have done ported there. So that it becomes easy for the maintainer to approve them and bring onto trunk. -- Sankar 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
Re: [Evolution-hackers] Introduction and Questions
On Thu, 2007-06-07 at 12:28 +0300, Philip Van Hoof wrote: On Thu, 2007-06-07 at 03:05 -0600, Sankar P wrote: On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote: It improves the situation by setting your url-string to have the basic_headers option. In the imap code of Camel, it will then ask for less headers (but still way too much). May be way too much for a mobile client; but not for a desktop email client. Sure you dont want your desktop mail client to have threading or show mail-size or have such basic things ? When I'm using Evolution on a laptop, I feel very mobile too. btw. This is a quote that I have from Federico, I think (remember) he said that to me last GUADEC. Although Very often I'm indeed using my laptop at an airport or something, using GPRS. Why isn't Evolution suitable for this use-case? I spend more than 99% of my internet time in a non-GPRS connection. Just because, I might want to check mail from an airport a few times in a year, I don't want my mail client to be a minimalistic bare-bones application all the time. I would rather use a web-based client at these times. And if I want to use Evolution even in such scenario, then there is an option to get basic_headers alone as well. (Such option was not there in last GUADEC though) I agree, though, that Tinymail's camel-lite memory improvements are less of a priority for Evolution. It's bandwidth work, though, is important in my opinion. Same for the Push E-mail capabilities. A major improvement it certainly isn't. Try comparing the performance of fetching all headers and basic_headers only. Some crude data which I collected a year back is at http://psankar.blogspot.com/2006/05/imap-performance.html Of course, you can look at the code to see what differs between the basic_headers mode and the normal one. And that will obviously make a big difference (the selection of the query is simply a lot smaller). But if Evolution is causing 900% of its bandwidth to be unnecessary, and the basic_headers mode saves 400% of that, there is still 500% of it that is too much. Which is the situation with basic_headers. The basic_headers option also doesn't implement condstore, which is quite important to safe bandwidth (if supported by the IMAP server). The band-width used by Evolution cannot be considered unnecessary, by comparing with a specific style that is designed for mobiles and intended to reduce bandwidth. It will be good to have CONDSTORE and ENVELOPE (and whatever-new) but it is not something that makes a user to say, Damn. I need this and cant use Evo unless I have it. But there are many other such things that needs attention and resources. There are more than 5500 bugs in Evolution and EDS in bgo alone and among these there is just only one bug that complains about bandwidth. This bug is filed by you and will eventually benefit the evolution project once you complete the patch that you are attempting there and being reviewed by Fejj. If Evolution (and hence Gnome as well) has to be successful in an enterprise level it needs more things like: Better Exchange support, Nicer and Richer UI, and more importantly Stability. So the Evolution project's roadmap should be driven based on these, instead of a feature that is not yet implemented by all the servers. I am not denying that it is good to have all these bandwidth savings but Feeping Creaturism(1) should be kept in check. However, if you feel this is the biggest blocker for a mail-application, patches are always welcomed :) The best way is to ask for the ENVELOPE and the remaining info using the normal BODY.PEEK method. It should be possible to specify per folder which of the headers are to be fetched, to make it really efficient. Do you really think any user on earth will really be interested in configuring what headers to fetch on a folder-basis ? The application should figure that list out automatically, obviously. I still don't understand why you need to get different headers for different folders. ps. In my opinion is also the imap4 project getting the majority of its design wrong. Although it looks better than the imap one, it's not the best way to use an IMAP server. If a project is going to write an IMAP client implementation 'today': they better do it right. A lot is changing in IMAP today (Lemonade, MORG, etc). It's important to get it right this time (the vast majority of E-mail clients totally suck at how they use the IMAP server, including Evolution indeed). Such a sweeping generalization !? Maybe, but I've seen quite a lot of their code, and they are indeed very badly programmed. Most of the custom Camel providers are in a very bad shape too, by the way. And ... camel-lite, camel upstream and its standard providers are also in a bad shape :( As you mentioned, IMAP (like any other technology) grows at a very high-speed. What you
Re: [Evolution-hackers] Not able to choose Sent folder
On Tue, 2007-06-19 at 13:10 -0700, Scott Herscher wrote: I've got a question about configuring which Sent folder to use. After configuring my Zimbra account in Evo, when I go to the Defaults tab of the account preferences windows, the UI doesn't allow me to specify the Sent folder to use for that account. I can specify which Drafts folder to use, but not which Sent folder. Anybody have any idea why this is the case? GroupWise provider did not want to do client-side sent-item tracking for various reasons. So this was implemented for Camel GroupWise provider of Evolution. What is this configuring of Zimbra account in Evolution ? You are talking about a Camel Zimbra-Provider ? Thanks, Scott ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar 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
Re: [Evolution-hackers] SpamBayes
On Fri, 2007-07-20 at 18:17 +0200, Rasmus Toftdahl Olesen wrote:
Hi There
I am the author of the SpamBayes using spam filtering plugin for
Evolution, so far i seem to have things working nicely (i based my code
on the Bogofilter plugin).
But there is one thing i am missing, i would like to be able to track
which messages have been marked as what - in SpamBayes you need to
untrain a wrongly tagged message before you can train on it tagged the
right way.
In other words, a message can have three states: not rated, junk or
not-junk. If the user wishes to train a message as e.g. junk i need to
know if it has previously been trained as not-junk (so i can untrain it)
before i train it as junk.
Rather than maintaining a database of seen messages on my own, i
thought it would be nice (as well as a good debugging feature) to be
able to add a custom header (X-Evolution-Spambayes-Plugin) to each
message as it is seen by the SpamBayes plugin, this would allow me to
see whether the message is new or not.
Is this possible?
Try using camel_medium_add_header. Attached is a patch. Verify.
Your plugin needs to be improved a little more. The bazaar sources link
leads to an empty page. If I download the source tarball, it does not
have configure.in so I can't run autogen. I needed that because your
configure script had 2.10 hard-coded. Trunk is 2.11.*
I have tried using camel_medium_set_header and camel_medium_get_header
on the CamelMimeMessage passed to the junk, non-junk hooks, but that
doesn't seem to work - but doesn't crash Evolution either.
Thanks for any insight you can provide.
My plugin is available form here:
http://halfdans.net/wiki.py/EvolutionSpamBayesPlugin
--
Sankar
Novell, Inc.
Software for the Open Enterprise™
http://www.novell.com
--- sb-junk-filter.c2007-07-23 12:49:45.0 +0530
+++ sb-junk-filter.c.vcs2007-07-23 12:32:02.0 +0530
@@ -302,7 +302,7 @@ void em_junk_sb_report_junk (EPlugin *ep
if ( header strcmp(header, PLUGIN_HEADER_HAM) == 0 ) {
em_junk_sb_report_non_junk_untrain ( msg );
}
-camel_medium_add_header ( CAMEL_MEDIUM(msg), PLUGIN_HEADER,
PLUGIN_HEADER_SPAM );
+camel_medium_set_header ( CAMEL_MEDIUM(msg), PLUGIN_HEADER,
PLUGIN_HEADER_SPAM );
gchar *argv[] = {
SPAMBAYES_CLIENT_BINARY,
@@ -327,7 +327,7 @@ void em_junk_sb_report_non_junk (EPlugin
if ( header strcmp(header, PLUGIN_HEADER_SPAM) == 0 ) {
em_junk_sb_report_junk_untrain ( msg );
}
-camel_medium_add_header ( CAMEL_MEDIUM(msg), PLUGIN_HEADER,
PLUGIN_HEADER_HAM );
+camel_medium_set_header ( CAMEL_MEDIUM(msg), PLUGIN_HEADER,
PLUGIN_HEADER_HAM );
gchar *argv[] = {
SPAMBAYES_CLIENT_BINARY,
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Central Delivery for Mail
On Wed, 2007-08-08 at 16:00 -0400, Matt Hollingsworth wrote: Hello all, I posted this on bugzilla, but was referred to here (actually, if I would have known about this list I would have posted it here first…sorry). First, I would like to start off with the fact that I'm more than willing to write the plugin that I'm requesting; I just wanted to make sure I'm not redoing some work that others have already done (plus, look for some advice on where to start). At the moment, with Exchange, I am able to pull mail from all my POP accounts into a central mailbox, using Outlook's little deliver mail here config option, where here in this case is my exchange mailbox. Thus, it is actually quite advantageous for me to use POP instead of IMAP, because I only have one mailbox to keep up with and back up. Plus, the email is cleaned off of the pop servers and stuck on my own server, where it's backed up regularly . Now, this could be emulated, plugging in an IMAP folder for an exchange folder. Basically, one could introduce the same deliver mail here dropdown configuration menu into the configuration for Evolution. In this case, a locally configured IMAP folder (or local folder of course) would be the destination choice. Outlook's feature actually could be trivially improved by making a per-POP-account configuration, but whatever. Either way, is this doable through your plugin framework? I don't know how abstracted away the imap folders are, but it seems like it should be trivial just to add a hook into the receive process that copies it to an IMAP folder instead of the local storage. I noticed that you can drag and drop emails from the local storage to IMAP folders, so the framework is there, I just need to call it, right? \ May be you can just create a filter, which will copy/move all the incoming mails in IMAP to your Exchange Inbox. If you are specific that you want to make it a plugin, instead of trying to make a hook, etc., you can write a plugin that adds a new filter to the existing filters-list. In the configure-options for your plugin, you can make it to choose whichever folder each account should have for deliver mail here. The plugin manual is available at http://www.gnome.org/projects/evolution/developer-doc/eplugin/ Thanks for your help :). I'm seriously itching to shedding off the last thing that is tying me to Windows. -Matt ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- 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
Re: [Evolution-hackers] Evolution plugin with Mono
On Sun, 2007-08-19 at 20:10 +0200, Manuel de la Pena wrote: Hi guys, I'm currently developing and application that I want to interact with evolution, specially with the contacts storage. I'm using Mono to develop the application and I was wondering there has been some work done regarding a mono and evolution integration in some way or I should use c as explained in http://www.gnome.org/projects/evolution/ developer-doc/eplugin/ At the moment, the mono-plugin-loader is untested and is experimental. It is planned to improve it for 2.14 So, at the moment, using C is the only option. What will your app. do ? You may need to use EDS APIs than write a plugin for Evo. if your app. wants to search/fetch the contacts. Thanks in advance :) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar P 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
Re: [Evolution-hackers] Evolution plugin with Mono
On Mon, 2007-08-20 at 12:01 +0200, Manuel de la Pena wrote: Hi, I can define the application as a self updating address-book, where the data of the contacts can be modified b y the contact themselves, this is aiming to solve the problem of sharing contact information when we have contacts that are not from a company or that do not have place in a LDAP, in other ways is a RDB with strong business rules. Currently the local copy of the contacts information is stored in a sqlite database I am not understanding the full picture of the problem that you are trying to solve. How are these contacts created ? You use a separate application to create these contacts ? And where is this DB running ? What other applications in addition to Evo. will make use of these contacts ? Will it be not sufficient if you just setup a LDAP server with no access-restrictions so that each user can create his own contacts ? Since LDAP is a standard protocol, many clients will already implement it. you can just start using Evo. without writing any code; if you have such a setup. However, and I was planing to develop a plugin to fetch the contacts from there to evolution, since implementing the LDAP protocol on-top of the server daemon seems to be to much work, at least for a first version. I would relllay apreciate any ideas to solve the problem, although seems that using c is the strongest and easiest answer at the moment. ... If you have a look at evolution/plugins/bbdb you can find code to sync Evolution's personal addressbook with gaim. You just need to copy and fit it to your server's needs, instead of gaim/pidgin. Thaks :) On 20/08/2007, at 10:06, Jacob Johnny wrote: On Sun, 2007-08-19 at 23:49 -0600, Sankar P wrote: On Sun, 2007-08-19 at 20:10 +0200, Manuel de la Pena wrote: Hi guys, I'm currently developing and application that I want to interact with evolution, specially with the contacts storage. I'm using Mono to develop the application and I was wondering there has been some work done regarding a mono and evolution integration in some way or I should use c as explained in http://www.gnome.org/projects/ evolution/ developer-doc/eplugin/ At the moment, the mono-plugin-loader is untested and is experimental. It is planned to improve it for 2.14 So, at the moment, using C is the only option. What will your app. do ? You may need to use EDS APIs than write a plugin for Evo. if your app. wants to search/fetch the contacts. Evolution Sharp (C# Bindings for EDS) can be used for this. Thanks in advance :) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar P http://psankar.blogspot.com 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
Re: [Evolution-hackers] Call for Release Notes
On Tue, 2007-08-28 at 09:13 +0200, Murray Cumming wrote: On Mon, 2007-08-27 at 23:42 -0600, Sankar P wrote: On Mon, 2007-08-27 at 15:24 +, Srinivasa Ragavan wrote: On Mon, 2007-08-27 at 15:03 +0200, Murray Cumming wrote: On Mon, 2007-08-27 at 10:00 +, Srinivasa Ragavan wrote: * FACE header and Contact image in preview pane Evolution has support to attach FACE header while sending e-mails and extract the header while receiving and show it in the preview pane. http://bp3.blogger.com/_G_VBnbGWMzs/Rpy_2WCctrI/BGo/qWewaum0Z-A/s1600-h/ZFace.jpg How can I tell evolution to use a particular image when I send emails? I don't see this in the preferences. Currently you can do it from Insert-Face in the composer window. It was supposed to have a preferences as part of plugin configuration. But I dont think it made it to svn. Sankar, am I right? Yes. You are. You need to use Inset-Face in the composer window. A few more things are still pending for this plugin. User should be able to set a photo from plugin-configure. The plugin should also support resizing the photo by itself. I did some of these changes but missed the freeze dead-line. So all these can go only after branching for Evo-2.14 is done. It seems obvious to me that this should be a per-account preference, or maybe it should be in the GNOME About Me control panel. As it is, it doesn't seem worth mentioning in the release notes, because it's not very usable if I have to specify an image file for each email that I send. Does that seem fair? Only the first time the user selects Insert Face he will be prompted for an image. On subsequent times, the old selected image itself is used. However, I accept that it is not so user-friendly at the moment. So I am okay to not mention it in the release-notes. Matthew: I was not aware of the ~/.face thing. I will try to use it in the next release (after the freeze is over). -- 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
Re: [Evolution-hackers] Difficulty of storing flags on IMAP server
On Thu, 2007-10-11 at 18:29 +0200, Philip Van Hoof wrote: On Thu, 2007-10-11 at 09:18 -0700, Ross Boylan wrote: I believe that some of the flags associated with messages (e.g., follow-up) are stored by the evolution client, rather than kept on the server. For at least some IMAP servers it should be possible to define custom flags on the server and use them. This would be very useful to me, since I'm accessing the mail from different locations. Any idea how big a job this would be to add? I might do it, if it's easy. BTW, is anyone planning on working on the problem that messages flagged initially flagged as follow-up and later flagged as completed still show up when you filter by follow-up? Search for CAMEL_MESSAGE_INFO_USER_FLAGS and uses of mi-user_flags in Camel (better search for -user_flags as that mi part is sometimes called info and sometimes with a bunch of casting around it called mi). In camel-imap-folder.c you can take an example from functions like flags_to_label. I guess you'll need to convert your user_flags to custom IMAP flags somehow. Not sure how easy that is. You can also add new tags (user_tags), which is similar to how user_flags work in Camel. It looks like those are already stored remotely. I think tags define the colour of the rows in your summary view (Important, Personal, Work, etc etc). I did some work to implement syncing custom flags support. So that you can have custom labels in addition to the 5 standard labels. The patch is at http://bugzilla.gnome.org/show_bug.cgi?id=211353 I tested it against a GroupWise IMAP implementation and it was working. IIRC, The only problem was all the flags were synced everytime instead of the newly set ones alone. And I needed to verify it was working with the rest of the IMAP servers. I stopped working on it because of personal reasons. If someone is interested can take up and complete. You'll have to write ui pieces for this too, in Evolution, of course. -- 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
Re: [Evolution-hackers] HTML composer as a standalone program?
On Thu, 2007-11-29 at 17:35 -0700, Zan Lynx wrote: On Sun, 2007-11-25 at 13:22 -0500, Matthew Barnes wrote: [cut] Evolution merely wraps GtkHTML's Bonobo-based HTML editor with additional buttons and menus that make it suitable as an email composer. There's a simple standalone test program in GtkHTML under components/html-editor/test_editor that may serve as a starting point for your needs. I believe Evolution uses its very own fork of GtkHTML, as I discover each time I try to file a bug against GtkHTML and get told its an Evolution-only bug. Only if you copy and paste, you will have this problem. Just click on the link. It will open correctly. Someone needs to go and fix Evo so it properly converts amp; to inside HREF attributes again. It's been broken this whole release. I hate having to save the email to disk and reopen it from Firefox in order to properly use the links in some emails. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- 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
Re: [Evolution-hackers] EPlugin newbie query
On Fri, 2008-03-14 at 17:09 +0800, Johan Jonathan Nugraha wrote: Hi, I've read the EPlugin manual docs and I've written my own code and XML files. I tried to compile but It seems my plugin is not working. After searching more I found out that i need to use --enable-plugins=all . Add your plugin sources to evolution/plugins/plugin-name folder. I assume evolution is the folder where you have your evolution sources built. Your plugin need to have its Makefile.am and follow autotools' logic. 1) Open the file configure.in your evolution source directory. 2) Search for plugins_standard and add your plugin-name to the list of already existing plugin names. (like 3) Search for plugins/external-editor/Makefile and add your plugin name as plugins/your-plugin-name/Makefile 4) Now run autogen with the argument --enable-plugins=all along with all other arguments that you have used earlier. 5) Run make install from your plugin directory. You should have your plugin installed. May I know how to use this option? Johan J.N ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar P ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error storing summary.
On Mon, 2008-05-12 at 15:34 +0530, Srinivasa Ragavan wrote: Sankar, Yet another solution for this problem will be to (re)write the local backend using the camel-offline-folder model, where every mail in the folder is stored in a distributed fashion, avoiding one huge mbox or huge files in a directory and also solves issues like unlink the file to delete a mail etc. Right. Got it. Something like what I do with GroupWise caches. Nice One. -Srini On Mon, 2008-05-12 at 14:51 +0530, Sankar P wrote: On Fri, 2008-05-09 at 23:57 +0200, Andre Klapper wrote: OK, so i managed to fuck up my POP Inbox for the third time in a few weeks, means: every time i switch to another folder i now get an Error storing summary (or something like that). i've seen some reports about this in bugzilla, e.g. http://bugzilla.gnome.org/show_bug.cgi?id=532049 . the last time i ran into this psankar told me to manually edit the mbox file and remove the offending email that misses the From line. this is not fun anymore when having a 600MB inbox file. a normal user is not willing to learn vim and emacs, me neither. I guess there should have been some recent commit which catalyzes this break-up-of-mbox. So, we need to just analyze and find out on what scenarios this is caused. Earlier, we used to get a folder-summary-mismatch and will not proceed at all. I have seen some heavy users being saved from that trouble, once we put in the code to auto-fix the .summary file. Broken mboxes are one scenario which we have not handled so far and it will be fixed. May be we will provide: evolution-fix-broken-mbox which will handle them. (/me remembers fejj's mail sent 2 days back) However, there are certain important things than fixing broken mboxes, like moving the summary to a db so that you don't have to hold every msginfo etc. which we are currently working on. So, operations like mbox recovery will have to wait for some time. We will try to identify why this has started happening frequently for you and will fix this soon, probably tracked in a bgo bug. Philip, Converting the local store from mbox to maildir will be a better option for the local accounts. It might create new problems and I will analyze about this and will come up with a fix if it does not cause any issue. And sqlite databases disk-blocks aren't spectacularly closely-written, when I last iogrinded (ground?) them. And mboxes/maildir are readable by all sane mail clients and hence makes sense to stick to some common standard than a single-filed-db. May be I will make a study of this after the db-based summary work is done. if nobody's working on a fix i should consider switching to thunderbird. We will fix this bug as it is critical and comes from a long time user, whom we want to keep happy :-) However, mail is a hog that tends to bite if it exceeds a limit, no matter which application we use and we will try to tame the beast. andre ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
On Thu, Jul 23, 2009 at 12:24 PM, Nirav Kumarkni...@novell.com wrote: Hi Andre, Migrating Wiki to live.gnome.org/evolution may be difficult with the high data content that evolution wiki holds. 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. I would believe that installing captcha and updating drupple should be able to provide the desired results.I am working with Novell IST and hope to have something positive in next few days. These two are the problems at the moment. But by moving to live.gnome.org, there are other benefits like: - we align more with the rest of the Gnome projects - one place to search docs for all projects and easy to link to docs of other project pages, say libsoup. - no need to create yet-another-new-account to edit evo project pages. anyone with a gnome account can edit pages. and above all, - Gnome sysadmins are easily reachable for non-Novell folks to report and rectify any problems, than Novell IST. There will be a single point of contact for admin related issues. 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 . Regards Nirav On Thu, 2009-07-23 at 12:06 +0530, Chenthill wrote: 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 -- Sankar P http://psankar.blogspot.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Manifesto
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 :-) -- Sankar P http://psankar.blogspot.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: Lifting the veil
On 7/9/2010 at 09:44 PM, in message 1278692045.6831.33.ca...@linux-e1q4.site, chen pchenth...@novell.com wrote: On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote: On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote: If Evolution staff will be willing to host our project sources within Evo git repo, we'll happily transfer our stuff there as soon as we have a first preview ready. Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be great to have you working in the same git repo IMHO [ not that it's my decision of course - I defer to Matthew/Chen etc. ;-] Certainly aim for hosting your project on git.gnome.org, but I'd still prefer it be split into a separate evolution-kolab repository similar to evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm told). It just keeps things more modular and it keeps us honest: our public APIs -have- to be complete since external projects don't have access to private in-tree APIs. The separation is not meant to be a barrier between you and us, just an implementation detail. While thinking about this, I just got a thought of why not a, evolution-collab-backends package which can hold all the eds collborative backends (that provides mail+calendar+address-book) such as mapi, exchange, groupwise with sufficient configuration options to choose what to compile ? This would help in making the api changes to all backends and keep external backends connected. I support maintaining the backend code in a separate package though. Its easier to provide updates to the backends if its not part of eds at-least with some distros (at-least with suse as I use it). More modules translate to more problems trying to build things. Oh I need to git clone another 10 modules. In my opinion, we should just follow linux kernel filesystems style (all under one tree). There can be any number of backends, but we can use sane config options to build only interested backends (for instance someone working on RHT may not bother about GW etc.) But for someone who wants to build evo with all backends, it is just one 'git clone' that he needs to do. Also, during release time, more modules contribute to more work for the maintainer(s). Changes made in core may not reflect in some low priority backends, if they are kept out of the tree. (oh that out-of-tree Scalix backend is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types) However, I am a little out of touch with the things and so I trust Chen/Matthew 's decisions as they know the current state. Just my 2 cents. Sankar - Chenthill. The process for obtaining a gnome.org account is here: http://live.gnome.org/NewAccounts Each of your developers should apply for their own account, but I would suggest waiting to do this until after you have a working public beta, as you'll have more credibility to the gnome.org admins then (which is not us!). Once you have your gnome.org accounts, you can clone your git repository on git.gnome.org by following the procedure here: http://live.gnome.org/Git/NewRepository Hope this helps. ___ 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
Re: [Evolution-hackers] Merging the collaboration providers in a single package
On 10/18/2010 at 07:01 PM, in message 1287408711.3126.11.ca...@localhost.localdomain, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2010-10-18 at 12:10 +0530, chen wrote: The other solution was to maintain all exchange providers in a single package, merging evolution-exchange, evolution-ews and evolution-mapi into a single package. Other collaboration providers like evolution-groupwise and evolution-kolab (yet to be upstreamed) will remain as separate packages. If we -have- to glob providers together I would prefer the alternate solution: merge all the Exchange providers into one git module, break GroupWise out from E-D-S into it's own git module, and leave the rest alone. This is not unlike the recent gnome-games debate on desktop-devel-list, except that we already have shared libraries for the common parts with fairly stable APIs (libebook, libecal, etc.). Jon's comments on the gnome-games issue reflect my own for this one: http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html I prefer not to have every provider in its own module. If we make changes in the baseclass, it will be ignored and won't go into unmaintained providers. More providers translates to more work for packagers downstream and also during the release time for maintainers as well, with not much benefits. Just my 2 cents. Sankar ___ 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] Merging the collaboration providers in a single package
I somewhat agree with Matthew on this one. If we glob all the providers together: a) Distro A doesn't want to support Provider X. You'd say we'll have a compiler option to not compile X. Why does Distro A even need the sources for X (and eventually ship it too)? For the same reason how it works in other projects, say Kernel. The linux kernel has dozens of file systems. Most of the distros are interested in a few of the filesystems only. But the reason why all are kept in the tree is because the changes will be updated in all the filesystems. It is easier to implement new build policy changes as well, if everything is in one place. b) If we put all the providers together, and this is from what I've seen happening, there is this tendency for code to get duplicated. Along with good designs, sometimes bad designs also get duplicated. Yes. Absolutley. In the same way, once a bad design is identified in one module and fixed, there is more chance of it getting fixed in rest of the providers as well, if it stays in the same tree. I prefer not to have every provider in its own module. If we make changes in the baseclass, it will be ignored and won't go into unmaintained providers. More providers translates to more work for packagers downstream and also during the release time for maintainers as well, with not much benefits. If a module has an owner, how is it unmaintained? The maintainer can go on a leave or focus on some other urgent new activity etc. (Say EWS). But I agree with Chen that Unmaintained is a poor word selection. As a packager, if we do glob the modules together, the first thing that would happen is a split-up of the built files into their own sub-packages in the spec. How is this any different from having two separate packages? Packager Hat Why ? We wont. We will just get one tarball update when released and build that with whatever configure options that suits our distro. We won't attempt to divide further. Like for instance, for kernel, we have only: kernel-pae/x86_64.rpm and no kernel-fs-ext3.rpm, kernel-fs-btrfs.rpm etc. All filesystems are inside the kernel.rpm /Packager Hat Just my 2 cents. I agree. I would not term as un-maintained providers. If they are really un-maintained, which means many bugs exist and people are not able to use it, it has to be pruned at some point. But certainly I see advantages to have the providers in a single package which would help us adapt to the API changes well, translations could be shared, packagers can look for updates for one package and maintainers would have less burden in releasing many packages. Turning it around the other way, if a change in the globbed package means nothing to the provider I'm using or interested in, what's in it for me to update the package? :-) None. Agreed. If a module is maintained, the API changes will eventually get there. Besides, you shouldn't be changing the base API that often anyway ;-) Agreed. Ideally ;-) Sankar ___ 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)
Hi Matthew, Sorry for the top posting. Your last few mails are displayed as I have attached below in a non-open mail client that I use (GroupWise). I have not changed my mail client in any recent time. So, it probably should be related to some change in the MIME code of Evolution recently I believe. Someone from the Novell (with access to GroupWise) may be able to help you with verifying this. It could be a bug in either GroupWise or Evolution sending. Just wanted to bring it to your notice. Thanks. Sankar VLVzpU2mYIiGQKY/++Zb145OfF2FUDlyRI5FvHOmhiEqwPzw8Oj4UE27lIaj8Wg0buomhkBAqZQe2 H3ly7+x4/6jF08fvbgYzI5+5otf+Iv//lW3XZaUlylV3g3rynKG0kvO88nYg0WAURW9aONjSVlUWc RitR+bz917YzQcuCoieTYTBAMwRBXVPnl0fjwYzebz/QMuvF4uGuecI! wMwUVFNJn ThqmXJ3/nut0TSbrfLg/kv/9N/9uzhj4/v3pkiTutYiQ7J1Y6I8+byctaMpoPhuApOWEtWM1E1hV D4U1dfAcBspllLLgwqBErAYH0uuev67Zq7jnMKId6+e6/ddecvXizOzjerVdd3fUmA4Jc9n/7w/b9 789XW/KOz58+e3CQ3GF2/8oO//va1sXOERL4k2So6RA8gfTo+mFvfsup6vWakIuqdv3tweDKbxWED Pg7DoDgDcmoGhCmlKlSMmlLX7NrUblLulctwOHz2yUd939d9N5h3YTyZ3Djxfvvs+t7B4ZAW/Qb3J 8Oj8cc/eOfio4/nVFJX5s1QEdTB0BGRi2ZNn+RyhZ5ywWTYlf7aZPz64fFoNts/PDqZn1R1HUNAhw LWC5s330RAzwCc++6TB0mZzYooNXGZdtt2N+/7taZ9pPlw5BfPz+/fec3pegB5s1h8+Bf/Yxhl6qx uBl1OjsAD1M6Ph+N2swS0QuG8z2BuLf3U4U9duzEbDf2gnu0djMZTT6FylSMCADCtQwVEatBzJtO8 3YGUjlMS3fRt0nJw/cqLx88Wm5V3WsUBRuev7J9M5od9Z03evjLUWczf+L9/5SyPYhz7oAZCoA6gx pAHXS6dZJK81wxeu3r16t7e0FehqjNBrCoAAnCOvCfKqUdHqtzuknlKItyn0nfdZtuWtOo2ULlmVI 8O5jmQXKyKlJLbIsk/evro1Xv3R+GwQFG/aiT/4i/8w2/8t69tLxZ1qGoMrWQGSSUruIBw48rhK0f 7g4BT39TTKde+6zrc9pJy3+527SZUHllzv0ul7ErquRSRxMLMfde1bbvj5AfucO9oMh11u742YdNh HRzQi08+8ut2JaIh1tCM1NhzFULzj3/pV588fvTo6ZPN5XKPsHJuEOIwhiaE6P1gNKzGQxcimEpKe duv+77fdTkVci5JYuV+t2v7brFdJy6qxlnMUZLS5RTHzcFwr2pqIhdjRWDVeMCkk9! HMm3lgdZX HWDU2s5IsqHg230xn+3dv3e2Wl9z1JWcrxcWqHjaD8Sg2FSAgW7ta7PqeS/IxOOeWq/XlD9+dH+1 T5S8uVheLSyRy3qtKzpmN2Xg4Hu0Pp/PR5KDZKyY9rxZPnlHtJtMxRIeEfj6ZAZKPjddkofJqbIwe ORccDDwRqoIIqoYqhhhD8ITIzF3ZiUqfcxGdzWdmRFR3qTw7PVu3W3M0GAwMoHAxE+YuM4/Gw73pe D6dzUaTQaiZy+nlZlQNzNswNh7JOe/fuHmNWJ2vwVfO19Z1qOS9C02AutEmKYszc4hIQIigasKoyi WVktebdaxrChWz+KZ2ztWgrokQqKlrNe27nkuuAsRYHR0c7O3tT2fzoH5zulgvl0OKd37y72z6zXq 7di70XLxcPubjV/zhVfM1xgGIRUQyJQQyMzRzEhCkFBUGMFVu27bk3Lbbi4vz9WZ9cHxC3oMyNd6U Xe3rGF1w3rnog07GJmJqs8l0Mpw4dLxJ235LSMNYT/eme/v7QxvnjwsSCYE/e//d1RqOXvtJ0lq81 xgBCM1AMoCgAagBmplxKaBiaMy57bfb3Xa5WoaqMjAk1wl770LjjNxw0MQY6lgF8p4CGJgqCXTLrb BEMSQ/Pzq+devG5eLMwMWqqptmo2om3vcdrBYAomZARC6gEQGoiqqaGLAkZeaimVUll7TabAr3l8v LTd8eHR8zgDH7GKPzwblJ3YTgnXeDahDBK1vftu16TX2hLJUP667bv3b93t17/WaTti3x0Edysdqu FhazbzBWwwralcYagYAcADIX7wOXzDnl3RZV1KRkBtA+dbnk9Wb9/PLcN5VFhyGgc04sVFUT60COk EwYOm53u91iY7l4Uc0sqgnz62++eev1e+354vz0SakkkiLQcDrNq0uB4pvZbL087z5+WL32GiOCio GBZgNQtLb0IgWFTTnloqpt166368Vyse3b4/lRm7thDM2wFmEij0QmWHIp212/66R! LkKVx3psb XzmYHuxP9+aO3NPHH25Wq2IlHMySZtSohgaQpfjB8WH37OzDb3/73q2bbObQ+rxDKcDGKSXNAEqg feqNNaXc59SlfrFaqumu3Q0no67rQqil7wHDNu+4zf22degGsdqb7g2qqmmawWjQjEYx+O1itbo4s 4q2WNyk0ZqIpVbzLjjnzTo/Obw6Gs1sON6cPWmmh2zGzKRFmEVLyankFJDUeeGsICK5S+3F+mIwmz BAt0uWtu3ZUrrSLrd5l06Orty8eXM6Ggfvo/MO0SFalzfb0zb3bekzWVcsVTgOENt26AOpRO9Fy67 beXGxbReHR8cKjKhGpECSi5SkOWcuLKKgBJiVi3LiIiCxjrGKUsp6tW0ojMfT0XQ+efX2qBn5UKkY qpEnUWFWLsXQBLQ42KFmQvAUvZe++FF86W0EMGhqXrH/7D//J9//6tdQbe6qzXKJgwGSKwamzJIVQ cAAUU2xCiI9VX5oo3AZAyIgHB0fH+8fDutBiM6hjy6acxSiCaiIqqmKaehzYrRkpRcSVU3ZZZns70 +G86ZpyFthA0EU8A+LvPkrv/LuN/8SfeCLszCozDv2UTiRDy5qYVYDQswssa6d6aipQblLXYxxXA9 iHWMTg/dmAMEzAHgTMvBoBmqkxQpAFsk5G7NTdIaHB4dHJyeD0VgdqPbZJFAIFPz9e/fLdtfcuH7+ /IWL/vz5472DY3QBXYUGkYCZlQUMfPDO1McqOnz1xq3FdmEGnAp5h94BERoKmCKJiDMgpFQyMxdmN S05A8sQw9HRYazq4WQKRMoKRKKac0kptbsOf/jgQZhMQwh/8K/+9ebDj7Rtf/4rX8lmmHvte4OS+y 53nXFhUURCLdFsFIIap9Klvkd0g8GYQvDOo5mqqhkjIAAYcGHhoiJg4MlNJtNxPfahSpKdQ8mZKuI Ytrn86PH757Z2t4+v37//RpvTa/ff+KM/+9OHDx/cv//WqB6aMlsxU0dEAKLMwmIq! qgBoZmiAi KPJhM2yiKj64PHlrDEgJDRQFgIgpBhCCKGpm8FgiIC5lE273Wy3mYsZdWw98/PLMxhG99u/8y+eP //g4tkH/eZ0PIyjvXlq87Wja6rZUFXVwMxMRPSlZhAQqc/Z1AxMwBQgFRazwoyIgGhqYAYApmqqzj kwJHKIBEBmlnMCwrbv+8JZswTblvbBs09GJ/ue0/ntq/NKC9gWX53tz0fvvfMIAnrzKiRIamYvHzZ RNGAVVSNfZZXMhZTJrKTcCZtaU9dNXb90IE/ex0gAYPCyOhA4FU05lZJFtM85mxGAJbvYbDa9zt3U HzUhlt5ZFsD5JC42/cHRZNO3e3VjnFkYXRAz8J6EKwSvLudMgMXA0EgUVcU0cwk+5lJEdTQYqpojq XwwQGX1BIjIyn2bzLiUYoq9iBCmXr2ns/PFcif1OftxA2pajEyNSroy922ii/Xz6eBWjF6YuiQADh yYZ0CwYiF4UyU1QKcqAijOGaKYrdbb8XAk2pKjKgStMDqfc0YABTCAVFLXtwBW2MSHvog6fPb+x+e 7nVTTx0/PvImwKBooM4jUzm6czD74uPfRFcY6eGHf970zM4pFUcEAzMAISNUUSEzUkMiXwqLalbxu 26qpK5E2ZxV9eTaoai6FHBXTru9VraQtxbhYbr7/0eOr937Cu5j61gt3vdB6m6MPi7NLxbqHdnHJV 48cWEDtKud9rPq+Z1VCUueziBlxYUIw50oWNFQFCsFX1qbCwp2KT8lUq1iVnKMPhUsuBYnMjHPpcs 5gy+1ma/jpn/7CyZ1PbXbbbr30pbjF1r7/3nM1yl1uJu58+cLhqEvtrArtJnEudazUkXJOJasoks/ K7D2AgIEBOANANAMF8DFsVy2zEJHzfr3deedKt8zCqrrrWkDwPmz6ct62NBjcuf9Tg+lB7vu6qmGy 77fZvvo/vzk/vqvM89neOpVhM2mqsfOeqjrWVUndZrUdNAMmYDAspeSdGZAnNVJhA! yzCav+v+v YlFxYupes7MwgxVlUjAheLjYJ2qW/7lomKq+ZXr1
Re: [Evolution-hackers] GroupWise mail issue (Was: (no subject))
On 2/16/2011 at 11:59 AM, in message 1297837796.2890.1.camel@zyxPad, Milan Crha mc...@redhat.com wrote: On Tue, 2011-02-15 at 23:16 -0700, Sankar P wrote: Your last few mails are displayed as I have attached below in a non-open mail client that I use (GroupWise). Hi, I guess it's the X-Face header doing trouble for GroupWise. Probably. Because your mail comes fine. Sankar ___ 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] Cache encryption
I'm working on Enterprise use of Evolution, and one of the big requirements is encryption of data at rest. The answer just encrypt the whole of the user's home directory only puts them off for so long. So I'm looking at implementing this directly in camel-data-cache, e-cal-backend-cache, etc. I'll probably do the encryption with a randomly-generated key, which itself is stored locally, encrypted with a password. That way, changing the password doesn't involve re-encrypting the whole of the store; you only need to re-encrypt the master key. It also means that we can tie the password for the cache to the password for the server; entering one will allow access to both. Hopefully, the changes required to code that *uses* the cache functionality should be fairly limited. Mostly it should be handled by extra arguments to camel_data_cache_new(), e_cal_backend_cache_new(), camel_db_open() and similar functions. I'm hoping that it's reasonable to declare that *filenames* are not sensitive, and that we only need to encrypt the *contents* of files. Does that seem fair? Any other comments on the approach? Will it be not simpler if we can make Evolution use a custom location for cache, that the user/root can set ? That way, we don't have to write (and more importantly maintain) yet another encryption/decryption library and instead just use a different folder for storing all secret/confidential data, which can be a custom mount point which runs on encrypted partition. From a distro point of view, libraries with security packages usually have extra maintenance overhead (Are you sure your package is not shipped to america-banned countries ? etc.) So I believe it will be a better idea if the [en/de]cryption capable packages are less in number. Sankar http://psankar.blogspot.com ___ 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] RFClue: Atomic folder updates
My memory is very rusty and I have not seen Evolution sources in more than 3
years now. However, we had a similar situation when we working on a GroupWise
backend and we used a trick to get the number of messages in a folder on
startup of Evolution (or when the user explicitly presses the getmail button)
and try to compare the mail counts between summary and server and update if
they differ (and obviously, after fetching new items in this delta)
I am not sure if Exchange server has such a count API. If so, it can be used
without breaking the summary code much.
Sankar
http://psankar.blogspot.com
On 12/3/2011 at 05:35 AM, in message
1322870713.5191.20.ca...@shinybook.infradead.org, David Woodhouse
dw...@infradead.org wrote:
We have at least three mail protocols now which are delta-based. That
is, you have a bookmark, 'sync key' or timestamp which represents what
the server *last* told you about a given folder. You say to the server
what changed since XXX, and get back a list of added/removed/changed
messages along with a *new* timestamp YYY.
It's a very efficient way to handle mailbox access, and it's used by at
least ActiveSync, EWS and IMAP+QRESYNC. In the Exchange protocols it's
called 'SyncState' or 'SyncKey', and in IMAP it's the HIGHESTMODSEQ.
(It's never *actually* a timestamp, since wall-clock time is a PITA. But
it's easy to *think* of it as as timestamp; the modification time on the
folder).
The problem is, we need to handle these updates *atomically*. If we
store the new timestamp before the changed messages, and we crash in the
middle of doing so, then we might miss out forever on the messages in
question. We'd restart, go to the server and say what happened since
YYY and we never get told *again* about the messages which came in
between time XXX and time YYY, that we didn't manage to fetch.
And if you do it the other way round and store the changed messages
first, and crash before you store the new timestamp, you get similar
issues (cf. bug 664637).
I'm not sure how to fix it. Looking at EWS first, since that's where we
noticed it, I pondered removing the camel_folder_summary_save_to_db()
call from the camel_ews_utils_sync_{created,updated,deleted}_items()
helper functions, so it happens just *once* at the end of the loop in
ews_refresh_info_sync() and commits all the changes at once. But just
deferring the camel_folder_summary bits isn't enough, is it? The
individual message_infos will have a lifetime of their own, and even
*internally*, camel_folder_summary_save_to_db() doesn't actually write
things out atomically using transactions in sqlite... does it?
Any suggestions or insight would be gratefully received...
--
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] Vacuum folders.db on expunge?
On 1/18/2012 at 09:17 PM, in message 1326901656.25967.14.camel@localhost.localdomain, Matthew Barnes mbar...@redhat.com wrote: I still find myself occasionally pointing users to the little shell script Srini wrote some years ago to vacuum out all your folders.db. Since moving to XDG base dirs I've kept an updated version of it here: http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb Usually after running the script, users report that Evolution feels fast and responsive again. Evolution really needs to be doing this on its own periodically, but I would rather the user not be aware of it. So no new pop-up dialogs or info bars or anything like that. I thought a natural place to tie a database cleansing into would be a folder expunge (and also File - Empty Trash), something most users do every now and then already -- or at least something we could instruct them to do directly within Evolution. Plus, users are already accustomed to a short delay when emptying trash, so a little extra delay there should be pretty inconspicuous. Thoughts? sqlite is used by not just Evo. But by other applications like Firefox, chromium, too. In openSUSE we found a solution http://gitorious.org/opensuse/vacuumizer/blobs/master/vacuumizer to do this via a script. May be the disros can run this script once a month on gdm logging in, so that all applications can be benefitted. Sankar ___ 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] Is it worth customizing the IMAP headers to fetch?
My intuition tells me the vast majority of users won't care or even understand what these options do, and those that do tinker with them probably won't notice any significant difference in download times. Implementing this in IMAPX is no problem, in fact I almost have it done. But I'm pausing now to question whether we SHOULD do this. I believe, we should. I have not worked on Evolution in a long time. But when the initial version of the patch was made to get only few headers, the performance improvement was unbelievably high. See: http://psankar.blogspot.in/2006/05/imap-performance.html (please scroll in that page to the see the stats (blogger template change regressions)) Since we fetched only minimal headers (after the patch), some filters setup using some non-fetched headers were broken and as a result this plugin was made iirc. So, my points are: a) We should fetch only minimal headers initially b) we should retain ability to fetch custom headers by being configurable c) We should tweak things to be in a more user-friendly way (as you mentioned in the last mail), instead of it being a plugin etc. Thanks. Sankar http://psankar.blogspot.com ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
