This is the planning page for Evolution 2.4. All big plans and decisions for the Evolution 2.4 release are described here.

The main theme for Evolution 2.4 is <i>quality over features</i>. We are focusing on performance, user interface improvements, robustness and community-building.

Timeline

Evolution releases are synchronized with release of GNOME. GNOME is released every six months, on a regular, predictable, time-based cycle.

The following dates are estimates based on previous GNOME releases.

Evolution/User:Andre: There is a work-in-progress timeline.

Evolution/User:pgoel: Looking at the current 2.11 plan (Feature freeze: 11th July) and our past experiences, I would rather recommend aiming at June 30 as the feature freeze for 2.4. This is to avoid the last minute feature checkins. This should be feasible since we are not aiming at adding a lot of features for 2.4.

Task List

Evolution/TwoFourTaskList aggregates all the tasks that would/may be taken up for the Evolution 2.3 development cycle.

Architecture

Some focus on more major architectural problems are covered on a separate page, Evolution/Evo2.4_Architecture.

Performance

It is commonplace for Evolution to consume well over 100 megabytes of RAM today. Some common user functions are slow, and many are not as fast as they could be.

We want to make Evolution feel light and snappy. These tasks are focused on memory use reduction and improving interactive performance.

We want to improve performance for common operations that make up the bulk of the Evolution experience, like switching from one mail message to another in the preview pane. These operations are not slow today, but they are not instant either. Near-instant performance for common operations will improve the user's overall impression of Evolution.

Software has a rich history of people spending large chunks of their life optimizing things that don't matter. Therefore, the mantra for this work is: profile before optimizing. You cannot optimize until you know what to optimize. Therefore a large portion of this work is devoted to timing and memory profiling.

Profiling Tools

• Valgrind is useful for tracking down memory leaks and memory usage.

• oprofile can help track down computational bottlenecks.

• memprof is useful for tracking down memory leaks and memory usage.

Evolution/User:Rodo GLib is using memory pools for data structures such as lists and hash tables. When using valgrind to track down leaks you will not see leaked memory allocated in memory pools. It is possible to compile GLib with memory pools disabled. They can be disabled at configure time.

Memory Use

Profiling Memory Use

It is not uncommon to see Evolution processes grow beyond 100 megs of RSS, and evolution-data-server processes over 50 megs. But where is this memory going?

We need to go through Evolution with memory profilers and valgrind to hunt down leaks, excessive memory allocation/fragmentation, non-const'd data that should be marked read-only, and other common problems. We can probably learn from (and participate in) the GNOME memory profiling optimizing efforts.

• Add a test for long term memory usage a la the idea on the GNOME wiki

• Run test suites on non-developer boxes. This means boxes which have (or are booted so that the kernel only knows about) 256 MB of RAM.

NotZed has written a profiling tool which give a simple visual map of memory use over time, a fragmentation visualiser. This is a low-resolution tool, but one that can visualise memory use over time and against user actions, it has a low impact on the running application.

This could possibly be matched with the simple backtrace generation code in a file descriptor debugger to provide detail of where the memory is being used.

Calendar and Addressbook

In EDS, calendar and addressbook data are kept in-memory for all loaded calendars and addressbooks, and it is not uncommon for EDS to grow above 50 megabytes in RSS.

• Calendar and addressbook data is also replicated in-memory between EDS and the Evolution GUI.

Evolution/User:Harish Calendar cache redesign offers a lot of scope for improving memory usage and performance. Shared backends (b/w evolution and alarm daemon) can avoid replicated data in memory. Moving away from linear walks for searching (by using indexed searches) can further help improve performance, in addition to the existing query optimizations.

Evolution/User: pchenthill Making the model handle the type checking of the calendar items (calendar/tasks) for adding them to the respective views. This would reduce memory buildups to some extent in EDS and also improve the performance.

Mail

We need profiling data for local mailboxes, IMAP, Exchange and GroupWise.

Summary files are kept in-memory for all mailboxes. For them to be moved to disk, in an effective manner, some architectural changes would be required. Some discussion on implementing Evolution/on-disk summaries has been started.

Interactive Response

Common operations should respond instantly. Each of the following should take < 0.20 seconds on common hardware:

• Evolution/User:BenM: Define `common'. I'd personally say 1 GHz / 128 MB for low-end, 2 GHz / 256 MB for mid-end. Evolution/User:NotZed I find starting gnome (before you do anything else) almost unusable on 128MB of memory.

• Evolution/User:VIvek Created a page where in the interactive response Evolution/profile_data is collected for Common user operations.

Helpful messages should be displayed in the status bar to tell the user if a time-consuming operation is underway.. Eg: First time loading in calendar - Evolution needs to tell the user if it has not loaded all events yet and still doing so

• Evolution/User:BenM: The goal should be to make things fast enough that we don't have to do that.

• Evolution/User:Harish: Need users to file bugs and tell us where they would like the status of the operation/backend to be known but Evolution is not saying much.

• Evolution/User:Notzed Remember some operations are dependent on external forces - e.g. network delays. Impossible to make such operations execute in a guaranteed time.

Seek accounting

A major cause of bad performance with evolution is related to poor seek performance. This is particularly obvious on laptops with slow hard disks. It's relatively easy to be fooled about this - particularly when testing evo. on a machine with lots of spare RAM. We need to use some tools to eject cached pages; available on request.

Evolution/User:Notzed I dont believe this will yield any fruitful results. The thrashing is to do with fragmented writes - flushing cached pages will not benefit profiling this. Indexing is the only code which does heavy seeking. It sounds like your system is paging, which will always seriously affect performance.

Synchronous I/O

For me - when Evo. is fetching mail - my disk becomes unusable, and my desktop slows to a crawl - my disk light hammers away like a smith on acid. Clearly, since the process of fetching mail needs pipelining / optimizing to ensure that we do asychronous writes, and sync/flush only when the full mail download (and spam filtering?) has completed. It's not clear to me what the disk activity is - perhaps re-writing indexes across a large set of mail boxes; I have 150 folders or so; if so - perhaps filtering can be delayed and aggregated to a per-box basis.

Evolution/User:NotZed Aggregating filtering per-mailbox complicates the failure cases and requires some more complex transactional processing than is required if you just process each message one at a time. You would have to store all new mail in a (new) queue and then process that queue in multiple passes based on the filtering processing.

Clearly indexing is a major performance bottleneck. A single global index would vastly improve memory and disk requirements and let caching work more effectively. The drawback is any corruption would require a complete index rebuild, and not just on the folder corrupted. Given that other tools are indexing the content anyway, there is a fair call for removing it from evolution iself.

The synchronous i/o is necessary, it is necessary to ensure data integrity (e.g. download mail, write to 'disk', delete mail, crash - the mail is lost). Without indexing, the synchronous i/o isn't much overhead, since most writes are large enough to mitigate it (early testing had shown this to be the case). Indexing is not done using synchronous writes.

Move to next/prev mail

We need to define some sample mails.

The point is not (just) to optimize GtkHTML's rendering paths. The point is to examine the entire process that is kicked-off when the user jumps to the next message, and optimize the slow parts. Fetching the message off disk/network, loading the message data, parsing it, determining what to display, destroying/creating widgets, rendering the data, displaying it. Is there prefetching we could be doing that we're not? Is our parsing code slow? Are we unnecessarily destroying/creating widgets when we could just clear/repopulate them? Does it take a while for the display to "settle down" if there are attachments? Etc. My general experience with the mail display is that there's a delay, like 0.3-0.5 seconds, right after I hit the down-arrow, and before the message is displayed. But this needs to be quantified and broken down through profiling.

Also, how do we measure this time? What is it now?

Open composer

Measure from the time the user clicks the 'compose' button to the time he can start typing in the mail.

How long does this take now? What are the slow parts?

• Evolution/User:Notzed The composer activation isn't particularly fast, making it a widget may help, but it may not significantly help. The bonobo menu's and toolbars aren't cheap either.

Switch folders

Measure from the time the user clicks on a new folder to the time when the mail summary is displayed and the UI has stopped updating.

How do we measure this? How long does it take now?

Mail movement operations

For example, moving a message between folders, moving folders, deleting messages. Are there areas where we are waiting for a round trip to the server where we could do something in the background (like, for IMAP)?

• Moving messages between folders is already done in another thread.
• Deleting messages (or setting other flags) doesn't have any round trips to the server (altho users complain that they want it to immediately sync the flag to the server, which would, of course, cause slowness)
• Moving folders is also done in another thread

For operations done in another thread, though, it might still block later operations the user starts until the first is complete (at least for IMAP) because:

• we only have a single conenction to the IMAP server
• we send 1 query at a time to the server

** this is partially a shortcomming of our implementation because we lock the CamelImapStore while an operation is in progress (we do something similar with my new IMAP4 code as well). Evolution/notzed it is a shortcomming of the implementation but nothing to do with locking of the CamelImapStore. The implementation is completely synchronous in all ways. **partly a shortcomming of the IMAP specification in that not all operations can be done in parallel (some combinations of query types can be performed in parallel, others can't)

We already try to "optimise" this by locking and unlocking in the loop to allow another thread to grab it and perform the next operation (meaning we don't hold the lock outside the for-loop that is moving all the messages)

The connection has to be multiplexed in different ways. e.g. multiple pipe-lined partial fetches of summary updates, content, perhaps even searches (searching over sub-ranges). This is the only way you're going to get any performance out of it and have a queue of operations which can be prioritised. The queue prioritisation has to happen in the backend.

Evolution/User:Nat I tried to clean up the disagreement that was going on here, but the IMAP experts needs to reach their own conclusions here.

Switch between mail, calendar and addressbook

Measure from the time the user clicks on a component button to the time the UI stops updating.

We probably need to consider first time vs subsequent switches.

Switch days/months in the calendar

Test this with an insanely large number of items in the calendar.

Open appointment

Evolution/User:Harish: Measure the number of backend calls to eds made by evolution during the course of opening a single appointment in the event editor/in rendering a view. There are a lot of redundant calls that need to be pruned out.

Handling attachments

Evolution/User:Harish: Calendar attachments do not reside in memory with the event objects, they belong to. However, in backends like GW, they are retrieved from the server and serialized in the file system even if the user may not have tried to open it. This can be designed such that a double click on an attachment displayed in the event-editor, triggers a backend request to eds, which in turn can fetch it from its cache/ download it from the server, on demand. This would drastically bring down the initial loading time of the calendar (first loading after account creation). (JIT fetching).

Looking up Free/Busy information while scheduling appointments

Evolution/User:Harish Test this with look-up on users who host their schedules on a WebCal or in the case of backends like GW, users who are hosted on other POAs (Post Office Agents). When does the user finally decide to give up if unable to get this information.

Evolution triggers off a free/busy request, while creating meetings (necessary) and when you double click an existing meeting item to read it (avoidable). This can be made more efficient by turning off f/b except during creation time. Alternatively, f/b search could be made a user-triggered activity, available even when one is not creating a meeting.

Addressbook operations

Evolution/User:sush Measure the time taken for performing various addressbook operations. Evolution/AddrBook_perf

Measuring interactive responses

Evolution/User:BenM: The best way to measure something like this would be to set up an automated test suite that measures what the human sees as response time: when the new UI pops up. For example, in the case of switching folders, the folder has been switched when the first screenful of messages pop up on the screen. There is also a qualitative aspect to measuring interactive response: does it feel like it is lagging, etc. This can help us look at what areas to tackle first. Also, timers could be inserted into the code to gather statistics about the length of operations. These could have little enough overhead that heavy email users (this means you Nat could try out the code for daily use. We could then get the data back and see which operations are the most frequent and how long they take.

Once performance problem areas are found, there are a few ways to look into the problem. For things that are computational, a tool such as oprofile can help. For other areas that involve round trips to the server, debugging helpers could be inserted to show how we are handling round trips.

Evolution startup time

This is both how long it takes to get to the mailer and also how long it takes for the first load of, eg, the address book.

IMAP Performance

• IMAP performance can be improved through pipelining and asynchronous startup.

As NotZed mentioned on the list, pipelining might not actually improve performance very much because it'd be hard to take advantage of it from the front-end.

Evolution/User:Notzed An alternative which may work nicely is to move to a different implementation model, which works on a locally synchronised folder, rather than working on the remote folder. Then the code only needs to implement a folder-synchronisation algorithm which can very easily be pipelined for maxiumum throughput. If the work is broken into fairly small chunks and a priority scheme layered on top, it should also improve interactive response. The main issue with this is that each client then needs a full copy of the remote mailbox, which may not be ideal in multi-user situations.

Fetching New Mail

Incorporating new messages off your POP server can be very slow. We need to profile this and find out the cause. Theories include:

• Spam filtering
• Synchronous disk writes
• Content indexing
• slow hardware
• slow network
• slow server
• busy computer
• insufficient ram in computer

EDS Performance

Bug Fixing

Automated Test Suite

Evolution currently has no automated test suite; at the time Evolution was developed, there were no automated test suites for UI testing of Linux desktop applications. Now, thanks to the atk ccessibility infrastructure, tools like LDTP are beginning to emerge.

We should choose one of these tools and build out a complete UI test suite for Evolution.

In addition to UI testing, we will want complete unit tests for all the Evolution components; at minimum we will need unit tests for all the EDS APIs. Unit tests for other Evo components can be added as well. There are already unit tests for Camel and for GtkHtml. There's also stress test for GtkHTML.

• Evolution/User:BenM: Can these unit tests be expanded to test for memory usage and performance? Of course, we want to look at the big picture (the entire ui, its memory usage/perf). But this could allow us to break part of the problem off.

Bug Areas

The Evolution team will have a new practice of tagging bugs in bugzilla with keywords marking a particular "bug area." Andre Klapper has already been busily adding keywords like IMAP, POP, i18n, printing and UI to the Evolution bugs.

These keywords will make it easier for Evolution developers to take on whole areas at a time.

Evolution/User:Andre: Well, haven't really been working on IMAP and POP keywords, but also on the keywords vfolders, filters, perf, security. Generally, the huge number of keywords should be reduced to a fairly usable amount to motivate people that report bugs to also add keywords (has to be discussed after moving to bugzilla.gnome.org in my opinion).

i18n

We should solve the outstanding i18n bugs at the beginning of the cycle, rather than continually pushing them back. We should also solve the intltool whitespace issue (doesn't preserve it iirc) that prevents us from using it on e-error files. We should also do a string audit looking for fuzzy matches across components in order to try and reduce the number of just-a-little-bit-off strings. Evolution/User:notzed AFAIK the intltool issue was fixed. The e-plugin skeleton example posted to the blog uses intltool for its e-error i18n.

• Evolution/User:Andre: Beside the possibility to search for the i18n keyword, string translation bugs should also be marked as blocking bug 36276.

User Interface

Menus and Toolbars

Menu items are not logically ordered in many places, some items are too prominent and others are not prominent enough. It is time to fix them.

Evolution/User:Andre: I have removed the list of menu/toolbar related bugs, since there were many bugs missing and querying bugzilla itself is much more up to date.

(Shouldn't we have a keyword for all of these?)

Evolution/User:Andre: I have set up meta tracking bugs about keyboard shortcuts and key combinations and a meta tracking bug about menu items rewrite and reordering. Please refer to them.

Rodney Dawes and Ben Kahn produced a new menu structure proposal during the 2.2 cycle, but there wasn't time to implement it and give it user testing before release. You can find their proposal here:

• Design team wiki

• Evolution blog about menus

The context menu changes did make it into 2.2, but the other changes didn't. These need to be implemented and tested on actual users, very early in the 2.4 cycle, so there is time to make changes before the release.

HIG Compliance

In various areas Evolution is not compatible with the GNOME HIG. This is in part because much of Evolution was developed before the HIG was even a twinkle in GNOME's eye.

But it is time to take a good look at Evolution's UI and bring it into better conformity with the rest of GNOME, and to better internal consistency. And, as the largest GNOME application, Evolution hackers might have some ideas for improving the HIG itself.

We will be consolidating all HIG issues in bugzilla under the 'hig' keyword, and we'd love people to help filing and fixing these issues.

Error Messages

Keyboard Navigation

Calendar UI Refresh

There are two current custom calendar view widgets, the "day view" which does day/work week views and the "week view" which handles the week and month views. Both are canvas based widgets that use e-text for inline editing, historicalling this was to do flicker free operations under gtk 1.2. There is a lot of redundant code in these widgets and they are difficult to make a11y and RTL compliant. Neither view supports multiple selection of events and the week view does not support drag and drop of events properly.

Other Stock and Canvas Based Widgets

In general, the more stock gtk+ widgets the better. Stock widgets reduce the amount of work for RTL languages and accessibility, and handle IM input automatically. This is also a clear win in terms of code maintenance.

ETable and GtkTreeView

Replacing ETable with GtkTreeView brings us in line with other GNOME applications, fixes issues with RTL and a11y support, removes canvas based code and removes an etable/treeview behavioural inconsistencies.

• Evolution/notzed except gtktreeview has significant performance problems which probably cannot be fixed without it being replaced

** Evolution/User:BenM: do you have bug #'s? *** Evolution/User:Notzed It was based on an experimental branch of evolution, the maintainers are aware of the issues.

ECalendar and GtkCalendar

We have our own canvas based mini calendar what is missing in GtkCalendar and fix it so we can get rid of our own canvas based one.

EMiniCard/EMiniCardView

There is a branch in CVS written by toshok makes the mini card view to not use the canvas.

Multiple Alarms

Sometimes the user comes back to Evolution after being away for a while, and there are many pending appointment alarms. Evolution pops up one dialog per alarm, which can result in a lot of dialogs and a lot of clicking to get rid of them.

Mobile Users

Evolution can be very noisy for people who use laptops or otherwise have very intermittent connections. Dialogs pop up frequently.

A new way of notifying users of lost connections should be devised.

• Evolution/User:Andre: Could be something similar to a "mail notification area" (bug 47373).

Screen Resolution

[http://bugzilla.ximian.com/show_bug.cgi?id=67787 67787 - Make Evolution usable at 800x600] (added by Evolution/DaveMalcolm; is this a priority?)

• Evolution/User:Jpr it might be better to start at checking 1024x768 and work from there

• Evolution/User:Andre ...and i guess that making Evolution usable at 640x480 will never be achieved...

• Evolution/User:Jpr we could look at that i guess, but I suspect 800x600 is the best we could do in the 2.4 timeframe, upon reflection its actually a better goal than my earlier 1024x768 and work backwards suggestion

Developer Platform

EPlugin Hooks

We want to add more EPlugin hooks, to allow plugin authors to do more. Here's a list of hooks we want to add in 2.4:

• Evolution/User:Notzed The importers should be completely re-written as plugins. There is room for much improvement in the importer api (with the current one it is too easy to write something that locks up the ui for extended periods and may easily go into infinite loops).

EPlugin Platform

We should set the goal of having plugins buildable in external, independent modules. This would require proper cleanup and installation of various headers and APIs.

API/ABI compatibility

We should be stricter about api stability in e-d-s and gtkhtml.

Evolution Sharp support for the calendar

Joe Shaw writes: :The calendar APIs leak out ical data structures which don't follow any sane coding convention as far as I can tell. This really throws off the Gtk# API generator. We could maybe bind those APIs manually, or write a helper library. It's been quite a while since I took a look at the issues and so I forget them exactly, but right now evolution-sharp only binds the addressbook APIs. We've gotten around this by loading the calendars directly from ics files in .evolution. Obviously this means we're missing remote calendars.

Logging Data Changes

Joe Shaw writes:

• It is difficult to know what data has changed, and when.
• This is an issue for us across all three data sources. Thanks to e-d-s, real-time changes to addressbook and calendar data are pretty easy to deal with. But unless we recrawl everything at startup, we'll lose any changes that happen while the beagle daemon isn't running. The fix for that might just be to ensure that beagled is always running, but because it's not a fixture of Linux distros, and because the Mono memory management is somewhat prohibitive for long running processes, this probably can't be fixed in the short term. With EPlugins like Nat's bbdb, addressbooks stand a great chance of becoming *huge* and a crawl at startup time may bog beagle down.
• The issue is a little more severe for mail because it's not in e-d-s, and because the volume of data associated with mail is usually much much larger. Essentially what I would love to see -- at least for mail, perhaps addressbook and calendar too -- is an on-disk journal format. It'd indicate new messages, changes to messages (flags, mainly), deletions and expunges. It could expire data after, say, a week. Paired with the summary changes above, it'd speed up mail in beagle by several orders of magnitude.

• Evolution/Harish The Evolution-GW backend hopefully would switch to a event-notification mechanism where the server would notify eds via SOAP of any add/modify/delete changes to cal/addressbook/mail data (server push model). This is a candidate for 2.4 to achieve better performance. Can explore if these notifications can be passed on to beagle real-time or used to write an on-disk journal.

• I don't understand why beagle can't do what it does with every other file it monitors, and monitor the file. It doesn't expect openoffice.org to notify it of all the diffs to a file when it is changed. Why would it expect more from evolution? Evolution/notzed

• Well, that is what Beagle does today. But mbox files, as distinct from documents, are frequently hundreds of megabytes. And they can change frequently. So it is an optimization. Evolution/User:Nat

Debugging Tools

We have a bunch of debugging tools throughout evolution, including multiple DEBUG environment variables, g_log usage, SIGUSR2 in e-d-s if turned on, the e-d-s logging interface that contains its own log handler, etc. We have basic documentation for these at debugging but we should ensure we are using these tools where appropriate.

Evolution/User:jpr If Glog goes into glib it could be a possibility.

Memory fragmentation visualizer

Evolution/User:notzed has written a memory fragmentation visualizer

File descriptor debugger

Evolution/User:notzed has written a file descriptor debugger

Adding support for googles coredumper

Evolution/pvanhoof wants to add support for [http://goog-coredumper.sourceforge.net/ coredumper] to configure.in (--with-coredumper). Coredumper makes it possible to create a snapshot coredump without the need for letting the application crash. On IRC Evolution/rodrigo and Evolution/jpr noted that this would be indeed a good idea. Evolution/jpr proposed to let a SIGUSR2 handler write a coredump.

Update: You can checkout a patch that adds support for google coredumper here

Features for 2.4

CalDAV Support

We want to support CalDAV in 2.4, so Evolution can talk to Hula and other CalDAV-supporting servers.

Web Calendar Support

We want to support web calendars that need SSL and authentication, as well as allow the ability to store the calendar to a WebDAV enabled server.

== Delegate Support == We would like to add support for meeting request delegation

Functionalities involved in delegation are

 : * The User should be able to send a delegate request to a non-attendee: * The User should not be able to change the contents of the meeting while delegating: * The User should be able to see the freebusy information of the delegatee: * The delegatee should be able to reply back to the organizer and optionally to the Delegator: * The Organizer should be able to decide whether the new attendee should be added

Tasks in Calendar

Some of the tasks to do for 2.4

Details for the above mentioned tasks are given below

• Progress status indication while loading the calendar items from the server: While the calendar items are retrieved from the server in EDS for groupwise calendars and in exchange process for exchange calendars for the first time, progress status must be shown in status bar. There is a signal already available in e-cal-view-listeners which can be used to pass the progress information from EDS to evolution.
• Disabling event editor UI at the recipient's end for meetings: The attendee should not be able to edit the meeting invitation. We also have to remove the scheduling tab in the event editor if the attendee opens the meeting request. This would cut down some unnecessary free/busy calls to the backend.
• Reducing the bonobo traffic: Some of the properties like static capabilities, calendar user's address, readonly state etc. can be stored in the client to reduce the bonobo calls to the backend. The backend can notify the client if the properties are changed in EDS.
• Optimizations of Attachment retrievals: The attachments are downloaded when the calendar items are retrieved from the server. This causes the initial load time to be very high. This needs to be optimized.

Address book Features

Evolution/User:sush List of address book features and important defect fixes that should go into 2.4 Evolution/Evo2.4/Address_book_tasks

Exchange connector features

Support for folder operations and Exchange specific operations in all the components:

Evolution/User:sush Description:

The main usability issue with the Exchange connector, is folder operations and some exchange specific operations are supported only at Exchange component.

We need to support all these from other components and get rid of Exchange button, once all the operations are supported elsewhere.

This needs support for folder hierarchy in all the components.

Sub Tasks

Evolution/User:sush sub-tasks and break down of each task. ExchangeWBS

Notes

Evolution/User:sush Related defects in Bugzilla:

267994, 231968, 259456, 257367, 262440, 266091, 262442, 273018, 307175

Groupwise Connector

Consolidation of Groupwise backend related plugins

New Features in Groupwise Connector

There are a couple of new things that the Groupwise Connector would feature for 2.4

Few details regarding each of the above mentioned features

• Junk Folder: The main issue here is that the Junk folder in evolution is a vfolder, as compared to the Groupwise junk folder which is a physical folder. Quite obviously the Junk folder in the Groupwise connector should work the way it does in a Groupwise client. This would require an interface from the server which would enable us the 'mark' and identify junk messages. :That apart, work should be done on client side to over-ride the default behaviour of Evolution, with regard to handling junk mail. This includes creating physical Junk folder, which would probably done using a plugin.

• Offline support: These are the goals for offline support on evolution for Groupwise provider: * cache/download the entire messages in the back-ground, thus avoiding a long wait, while evo downloads all messages while going offline.: * switching to offline mode, should display the entire folder tree and not just those that have been marked offline. In essence, all folders should be marked offline by deafult: a tracker bug has already been filed in this regard

• Proxy support: for details on proxy support follow -> Evolution/User_talk:Psankar

Apart from this, fix critical bugs.

Beagle requirements for Evolution 2.4

Following are some of the Beagle Team requests for Evolution 2.4.

Few details regarding each of the above mentioned features

;Seekable summary format for mail:Beagle expects sort of hashed-summary entries which can point to mails or a subset of mails which are fairly easy and less time-consuming to walk through and find. Evolution keeps the entire mail summaries in memory which Beagle doesn't want to.

• Evolution/User:Vvaradhan: With NotZed's mail-remote plugin, we can fetch mails irrespective of backends (though, it always fetches from the server, however, it depends on the implementation of individual backends), listen to change notifications on mails etc. However, on the downside, (ie) when evolution is not running, Beagle will have to use the current way of indexing mails. So, some of the hacks that Beagle uses today to determine account/folder names etc have to be still used.

• Evolution/User:JoeShaw: The requirement to run Evo is probably a showstopper in terms of completely switching over our mail backend usage to it. I think we can probably do change notification using it, but we'll still have to parse most of the mail as we do today, and unlike what Varadhan said, we'll have to forego the other backends as a result.

The mail-remote plugin exposes CORBA interface. So, the client has to just create the stubs from the idl file and access the object. A possible client implementation for Beagle would be 1) Writing a "glue" code in C which accesses this object and provides a nice cleaner API through evo#. 2) Beagle using this evo# API determines the availability of object and behaves accordingly. (Hope Joe can fill this with more details).

• Calendar items via text export:A textual representation of each calendar items that occurs. Ex: "Staff Meeting, 11 AM every Thursday". And each time we query, we get all the current events.

• Evolution/User:Vvaradhan: I have written a e-cal-glue.c in evo# module that uses the exposed APIs from e-d-s to query for calendar events. It returns back the "string" representation of the icalcomponent. This is just a test wrapper. The helper functions will be modified to fill-in a structure containing only the necessary fields.

:(Expiry issues can probably be dealt in Beagle).

• Default to offline caching:Enable "offline caching" mode, by default, for imap, groupwise and exchange accounts.

• Evolution/User:Vvaradhan: Whenever a folder-object is created, it should by default have "offline" flag set to true.

• Easy contact/appointment viewing:Contact/appointments should be viewed in their respective editors without invoking evolution UI. (move the editors to e-d-s).

• Evolution/User:Vvaradhan: Editors can be invoked from the commandline with -c option. (editors can be moved to e-d-s for 2.6).

• Evolution/User:JoeShaw: The -c option just opens a component. How do we open individual contacts and calendar entries?

• Evolution/User:Vvaradhan: Its not with -c option now. In Evo 2.4, individual contacts and calendar items can be opened just like mails using the respective URIs. For calendar it will be like "calendar:///?source-uid=<value>&comp-uid=<value>[&comp-rid=value]" and for contacts,

"contacts:///?source-uid=<value>&contact-uid=<value>". All "value"s should be properly encoded like that of a normal URL.

• Be able to reply, forward, delete, set as spam:These are in priority order, most important is to be able to "reply".

• Evolution/User:Vvaradhan: The mail-component already handles open/reply/reply-all options from the command-line. Similarly other options can be implemented. (Before that a basic verification needs to be done for the existing options).

• Evolution/User:JoeShaw: How do you do reply from the command-line? Is this a new 2.4 feature?

• Evolution/User:Vvaradhan: Yes, it is available, however, not sure whether it is a new 2.4 feature or a hidden one. It is working fine.