Re: [Evolution-hackers] Patches to fix bug 311512

2007-02-15 Thread Karl Relton
Hi Jeffrey

Over on bugzilla for bug 311512 I've been proposing an approach for
fixing the bug of new mail notifications...

Jeffrey wrote:
 Karl: this is how we originally implemented this feature... I don't remember
 what all the problems were, but it's got at least these problems:
 - it won't work for folders other than Inbox
 - it won't work unless the user enables filtering for IMAP/MH/Maildir (aka
 Storage) account types.

Yeah - those were among my fears of this approach. However, I still guess 
email 'as it comes into evolution' ought to be the right direction.

A question about Imap (and other storage type) accounts: when a new mail appears
on the server in a non-Inbox folder, how does Evolution detect its presence 
either the user 'visiting' that folder (forcing Evo to do a quick re-sync) or 
storage-server (e.g. the Imap server) 'pushing' the info to the client?

More specifically, where in the code might I see this?

Another completely alternative approach would, I guess, be to look at the 
'stand-alone' notification programmes that are out there (e.g.
Perhaps a case could be made for moving the 'notification functionality' out of
evolution client completely and into a standalone sub-programme?

Just more thoughts in search of a solution ...

Evolution-hackers mailing list

Re: [Evolution-hackers] The recent camel-lite improvements

2007-02-15 Thread Philip Van Hoof
On Wed, 2007-02-07 at 21:40 +0100, Gilles Dartiguelongue wrote:
 It'd be nice to see the work for IDLE make it to mainline too.

I would like to warn that the work for IDLE pulls nearly each and every
change to the IMAP code with it, as a dependency.

The IDLE work requires changes to dealing with expunges, changes to the
camelstream type (it needs non-blocked reading, and with the current
design of Camel there's also no other way to read the IDLE responses
correctly), changes to the imap-command type and really significant
changes to the locking of the IMAP provider's connection.

It also enjoys the condstore support, a lot. As well as that it enjoys
the rewrite of the imap_update_summary implementation. That's mostly
because the index of each summary item must be exactly correct with the
sequence on the IMAP mailbox.

Imagine that not being in sync and a push happening on that sequence. A
push like an expunge or a flags-update: the wrong message would be
changed locally.

That would be like a bug that the user experiences as data loss. So it
really really has to be absolutely correct. This is also why extra
checking has been put in place in both imap_summary_update, imap_rescan
and the new imap_rescan_condstore implementation: it *HAS* to be correct

As a developer myself, I'm totally pro pushing the changes to Evolu-
tion's Mailer component. You would indeed have instant changes and even
eventually incrementally filling up the folder-view while you are
downloading the folder(this is possible, yes. Like Polymer .. yes).

But  from a stability point of view, it *would* most likely
destabilize the product ... Evolution at this moment.

And that is must likely not interesting for Novell. Am I wrong or right
about this feeling of mine ? :-)

I would, however, aid the person that gets my work into a RD branch of
Evolution or whatever. Evolution, however, isn't *my* focus project. And
this would consume my entire own focus. I will help the person who makes
it his project. That's what these notes are about.

Evolution-hackers mailing list

[Evolution-hackers] Patches in need of review (E-D-S)

2007-02-15 Thread Kjartan Maraas
Following up on the list I made for Evolution. This time e-d-s:

Bug 363102 – E-D-S crash (and potential data corruption?) due to thread
race condition

Bug 359806 – Non-ascii characters generate trash in address lists

Bug 384044 – possible memory leak in icalvalue_decode_ical_string

Bug 394567: ical file ends \r\n and fbtypes

Bug 331099: evolution allocates 65GB of memory then pages to death on

Bug 360807: Memory leak when using SMTP AUTH

Bug 373495: e-d-s doesn't honor prefix

Bug 400629: EDS fails to distcheck

There are lots more that are fairly easy patches to optimize stuff or
clean up code, but I think those should be secondary to the more serious
issues like crashes and stuff not building etc.


Evolution-hackers mailing list

Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)

2007-02-15 Thread Sankar P
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. 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.


Evolution-hackers mailing list