Re: [Evolution-hackers] RFClue: Atomic folder updates

[Sankar P]

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
 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?

[Sankar P]

>>> On 1/18/2012 at 09:17 PM, in message
<1326901656.25967.14.camel@localhost.localdomain>, Matthew Barnes
 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?

[Sankar P]

> 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

Re: [Evolution-hackers] Evolution and Exchange on Mac OSX

[Sankar P]

On Mon, 2006-08-21 at 12:20 -0500, Jeffry Lane wrote:
> I have successfully installed the the Evolution 2.6 package on my mac.
> I have also read the readme which states the Exchange connector is
> include in the package install.  When I try to configure an email
> account, MS Exchange is not an option.  According the pdf manual, the
> connector is not installed.  How do I install it, activate it, or
> where can I download the ported version for OSX?

You are using an old build. Please see
http://mail.gnome.org/archives/evolution-list/2006-August/msg00208.html

And use the installer mentioned there.

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] Reviewing imap_update_summary

[Sankar P]

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] [SPAM (contact help desk if this is not spam)] String and UI Announcement Period.

[Sankar P]

On Sun, 2007-01-28 at 02:01 +0100, Andre Klapper wrote:
> String and UI Announcement Period means that new strings and new UI
> should be ANNOUNCED, for example if a "IMAP Headers" feature is suddenly
> added, without letting anybody of your translators know.

Sorry for missing it. Will do it right-away.

> And marking UI-visible strings as translatable would also be a nice
> benefit.
> 
> also see http://live.gnome.org/TwoPointSeventeen .
> 
> fighting with windmiles, i know. just for future reference.
> 
> andre
> 
-- 
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)

[Sankar P]

On Fri, 2007-01-26 at 16:59 -0600, Matthew Martin wrote:
> I'm working on templates for evolution. 

All the best for the completion of this feature/bounty. Many people have
taken this but none made as much progress as you have.

> 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)

Avoid using magic numbers like "return -2". Put them to an enum and use
it.

Definition of save_template is not there in the current.patch

I will send the detailed review comments soon after applying the patch
and using it, in a day or two.


> 
> ___
> 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] Where to put UI items for templates (Bug #127529)

[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. 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)

[Sankar P]

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.

- 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 ?"

- 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) .

- Reopening a template and saving it again should not create a new
template.

- 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)


> ___
> 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] Where to put UI items for templates (Bug #127529)

[Sankar P]

On Tue, 2007-02-20 at 00:42 +0100, guenther wrote:
> On Fri, 2007-02-16 at 14:09 +0530, Sankar P wrote:
> 
> > 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.
> 
> This is not how I understood the long-time user-requested feature of
> Templates. See my previous mail -- what are we really discussing here?
> 
> 
> > - 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.
> 
> Exactly. This approach introduces a *lot* of UI issues and different
> concepts, that need to be discussed before implementing it.
> 
> 
> > - 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 ?"
> 
> Where did the "Template name" come from?? So far I haven't seen any
> mention of an additional text input field for this in the Composer, or
> any other way to define it. I did not get the impression either this has
> been planned when discussing Templates with Matthew on IRC.
> 
> 

I am not aware of what you discussed with Matthew on IRC regarding this.
But the initial bounty description have always stated that the Template
folder should be a special folder that is available under "On the
computer". http://www.gnome.org/bounties/Mailer.html#127529

> > - 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) .
> 
> NO. This is totally wrong.  Example: Every bloody text editor. Saving a
> document does not close the editor.

Accepted.

> 
> 
> > - Reopening a template and saving it again should not create a new
> > template.

This behavior lead to the above comment.

> > 
> > - 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.
> 
> Which code to save the Template. What name (again)?
> 
> The current implementation is just like Drafts. The list view is. And
> there is no uniqueness other than a mail is a mail is mail. Templates
> (currently) are stored using the Evo internal (actually, account
> specific) backend. That is a single mbox file, internally.

As I said in my earlier mail, what we get when we save a message as a
Template is something that Evolution only can understand. 

If it is just location-independence, How often do you think a Evolution
user will switch across various computers ? If it is very often, he
should not use a thick mail-client and rather be using a thin web-based
client.

However, it is often that a user may be having Evolution running on
two-three different computers (Home/Office). And he might want to have
the same set of templates across his machines. He can do it if once he
saves the template in one machine and import it in the other machine as
well.

Having the template stored in a server is a good idea when we have a
common standard for template messages. Like, ${DATE} in a template
message will mean any mail-client should expand it to the current-date.
We dont have a common open-standard at the moment, and we are not trying
to create one.

The templates that we are trying to implement in Evolution are more like
the templates that you have in your mobile-phones for sms. That's why I
said Templates that we want in Evolution are more like the SIGNATURES
that we already have.

By dis-ass

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

[Sankar P]

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)

[Sankar P]

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)

[Sankar P]

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 a

Re: [Evolution-hackers] [Evolution] ANNOUNCE: Evolution 2.10.0, Evolution-Data-Server 1.10.0, GtkHTML 3.14.0 and Evolution Exchange 2.10.0

[Sankar P]

On Wed, 2007-03-14 at 12:44 +0530, Harish Krishnaswamy wrote:
> On Tue, 2007-03-13 at 23:04 -0400, Claudio Saavedra wrote:
> > El Tue, 13-03-2007 a las 13:08 +0530, Harish Krishnaswamy escribió:
> > > Hi All,
> > > 
> > > The Evolution Team is pleased to announce the release of
> > > 
> > > * Evolution 2.10.0
> > > 
> > > * Evolution-Data-Server 1.10.0
> > 
> > I'm sorry to spoil the fun, but you guys left
> > 
> >  g_print ("\n\a Header string finally is ** \n%s\n",
> >header_spec->str);
> > 
> > in e-d-s, camel/providers/imap/camel-imap-folder.c:2367, which is pretty
> > annoying, specially because of the '\a' (i.e., a beep every time a new
> > mail arrives or a mail is moved to another folder).
> > 
> > This appeared with a patch for this bug[1], I tried to warn but it seems
> > it got unnoticed. Hope it's not too late to fix this.
> > 
> > Claudio
> > 
> > [1] http://bugzilla.gnome.org/show_bug.cgi?id=400841
> > 
> 
> You are right - this *is* an annoyance and should have been pruned
> before the release,
> but it is a tad late - the tarballs are already out.
> 
> I also feel that this g_print statement should be conditional on the
> debug flags turned on - and should not add noise to normal usage. The
> use of \a looks superfluous too.
> 
> Varadhan/Sankar : Can you wrap the statement within a suitable DEBUG
> level check and get the change committed asap.  TIA.

I have committed a change by which the debug statement is made
conditional.
http://svn.gnome.org/viewcvs/evolution-data-server?view=rev&revision=7654

With the released version, you will get a beep sound only when Evolution
is launched from a terminal and there are new mails in a folder. IMHO,
that is not so critical that we need to make a dot-release for this
patch alone. 

> Thanks,
> Harish
> 
> 
-- 
Sankar

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Security vulnerability in APOP authentication

[Sankar P]

Thanks for reporting this issue. I have filed this as
http://bugzilla.gnome.org/show_bug.cgi?id=424373 for better tracking.

-- 
Sankar

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Evolution integration into bespoke database

[Sankar P]

On Fri, 2007-04-13 at 15:22 +0530, Srinivasa Ragavan wrote:
> Hi Kye,
> 
> I really dont understand the work you are doing and the use cases too.
> But if this is what you are trying to achieve, you can write a camel
> transport provider to do this. Evolution has two providers (SMTP and
> sendmail) which sends the mail from Evolution. In your case, it has to
> save/store the DB or whatever. The account you create should specify
> that as the provider for sending so that it works out clean.
> 
> Look into evolution-data-server/camel/providers/ for sendmail and smtp.
> You may have to create one more there for your provider.

Hmm. I guess you wouldn't need all such heavy-work. You can create an
outgoing filter which will, "pipe to a program" where you can pass it
onto your db. 

But as Srini said, I am not so clear about your usecase though.


> 
> -Srini.
> 
> On Fri, 2007-04-13 at 10:31 +1000, Kye Macdonald wrote:
> > Hello All,
> > 
> > Posted on the wrong mailing list so re-posting here.
> > 
> > We are in the process of developing an inhouse database and CRM
> > package and I want to integrate Evolution as its mail client.  ATM we
> > have the database spawning a new evolution email message with all the
> > contact details in without a problem.  What I would like it to do
> > though is once you press send have the database lift the content from
> > the email and save it.  We have a work around that picks up the mail
> > from the mail server but I would like the database to interact
> > directly with evolution.
> > 
> > Has anyone done this already or know a straight forward path to
> > achieving this?
> > 
> > regards,
> > 
> > Kye Macdonald 
> > ___
> > Evolution-hackers mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers
> 
> ___
> Evolution-hackers mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Sankar

___
Evolution-hackers mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[Sankar P]

On Sun, 2007-04-22 at 17:37 -0500, Matthew Martin wrote:
> 
> 
> On 2/22/07, Sankar P <[EMAIL PROTECTED]> wrote:
> 
> > >
> > > - 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".
> 
> Where should the name be stored? This is also not listed on the
> bounty. 

This should ideally come as an e-table column, just like sender, from,
subject etc.

> 
> 
>
> 
> 
-- 
Sankar

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Plugin and menu icons

[Sankar P]

>>> 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

[Sankar P]

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:
> 
>   
> 
> 
> 
> Thanks,
> 
> Jeshua Lacock, Owner
> 
> 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

[Sankar P]

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

[Sankar P]

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

Re: [Evolution-hackers] Not able to choose Sent folder

[Sankar P]

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] Multiple Trash and Junk folders

[Sankar P]

On Tue, 2007-06-19 at 12:33 -0700, Scott Herscher wrote:
> Hey all. I'm trying to track down a problem within the Zimbra Evolution 
> Connector. It seems that everytime I setup a Zimbra account, my mail folder 
> list contains two Trash and two Junk folders.  One of them has a folder icon, 
> and one has a "local" icon.  Why is this happening, and what can I do to make 
> it stop?

You need to use CAMEL_STORE_VJUNK and  CAMEL_STORE_VTRASH flags
appropriately in your provider's store. 

> Thanks,
> 
> Scott
> ___
> 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] SpamBayes

[Sankar P]

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

[Sankar P]

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

[Sankar P]

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

[Sankar P]

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

[Sankar P]

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.

Matthew: 
I was not aware of the ~/.face thing. I will try to use it in the next
release (after the freeze is over).


> -Srini
> > 
> > > Evolution can also fetch the image of the sender from addressbook and
> > > show it in the preview pane.
> > > http://gnomebangalore.org/~sragavan/2.12/contact-image.png
> > 
> > 
> 
> _______
> 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] Call for Release Notes

[Sankar P]

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

[Sankar P]

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] GMail IMAP support in Evolution

[Sankar P]

On Thu, 2007-10-25 at 10:13 -0400, Jeffrey Stedfast wrote:
> I have a feeling, though, that the main reason Evo is so much slower
> than Outlook is due to the summary info gathering which (used to?)
> grab
> all the mailing-list headers as well as the normal stuff in order to
> be
> able to vfolder on mailing-list.


I have made this as a configurable option and if the user does not want
to fetch mailing-list headers he can choose to. (Though the default is
that it will fetch)

However, I am doubtful though how many users will be aware of what a
mailing-list header is. 
> 
-- 
Sankar P
Harver's Law: A drunken man's words are a sober man's thoughts

 Novell, Inc. 
Software for the Open Enterprise™
http://www.novell.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Exchange MAPI Connector

[Sankar P]

On Tue, 2007-11-20 at 23:48 +0530, Srinivasa Ragavan wrote:
> Cody,
> 
> You compiled from the branch? If so the provider/server type is
> "Exchange MAPI". It is very much possible that the plugin is disabled
in
> your first time setups (Sorry these all are the bugs to be fixed). So
> you create a dummy/local account and enable the plugin and create a
new
> account of type Exchange MAPI.

I guess he just created an exchange owa account and not a MAPI thing.

> 
> What is there in the branch is GAL/Contacts mostly works, Calendar
> implementation is partial and folder list/summary is done and partial
> mail fetch is there.
> 
> -Srini.
> 
> On Tue, 2007-11-20 at 09:38 -0600, Cody Ray wrote:
> > I am compiling from svn just for this reason, but a strange thing is
happening now and it may be due to permissions or something I am
missing, but when I launch my freshly new compiled Evolution the
Evolution Setup Assistant allows me to fill in name, org, email address,
etc. and then I can choose my server type (I choose Exchange), but then
I am unable to go forward as the Forward button is grayed out.  Any
ideas?  Using Mint Linux with freshly checked out and compiled:
> > 
> > evolution, evolution-caldav, evolution-data-server,
evolution-exchange, evolution-gconf-tools, gtkhtml and libsoup.
> > 
> > From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Holger Goetz
[EMAIL PROTECTED]
> > Sent: Tuesday, November 20, 2007 2:59 AM
> > To: Srinivasa Ragavan
> > Cc: evolution-hackers
> > Subject: Re: [Evolution-hackers] Exchange MAPI Connector
> > 
> > Hi Srini,
> > 
> > thanks for the good news - no worries i don't blame anyone - i know
how
> > hectic dev can be ;-)
> > 
> > Thanks,E
> > Holger
> > 
> > 
> > On Mon, 2007-11-19 at 23:12 +0530, Srinivasa Ragavan wrote:
> > > Holger,
> > >
> > > I think by end of this week or so I should be able send out a
> > > preliminary release with binaries as well.
> > >
> > > Don't blame me if I'm late. Things are really hectic here.
> > >
> > > -Srini.
> > >
> > > On Mon, 2007-11-19 at 15:35 +0100, Holger Goetz wrote:
> > > > Hi,
> > > >
> > > > as i'm urgently waiting for a exchange 2007 enabled Evolution -
is
> > > > there any light on the horizon for preliminary version? -
> > > > Actually a description on how to compile would be fine - Seems
like
> > > > specially the question about what libs (libmapi 0.6 and some
samba4)
> > > > need to be installed is important. As right now this kills all
my
> > > > tries to get a libmapi enabled version compiled out of the svn
sources
> > > > below...
> > > >
> > > > Thanks for any hints,
> > > > Holger
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote:
> > > > > Hello everyone,
> > > > >
> > > > > For Evolution 2.22 we should be having MAPI based Exchange
connector
> > > > > which developed in parallel with Openchange based libmapi. The
team is
> > > > > currently working on that and the code is currently maintianed
at GNOME
> > > > > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and
> > > > > evolution-data-server)
> > > > >
> > > > >
http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/
> > > > >
http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH/
> > > > >
> > > > > I created the branch yesterday and we committed our week long
effort
> > > > > there. We now have a working account setup plugin, base
camel/calendar
> > > > > code and a partially working addressbook impl. Things should
get to a
> > > > > working shape in another week or two. I hope that soon, Johnny
would be
> > > > > able to create a OpenSUSE Build Service repository (rpms for
OpenSUSE,
> > > > > Fedora, Ubuntu and few more) for Evolution and its
dependencies so that
> > > > > users can install the rpms and get a feel of it even before
the
> > > > > release.
> > > > >
> > > > > -Srini.> > > > > Evolution-hackers@gnome.org
> > > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers
> > 
> > ___
> > Evolution-hackers mailing list
> > Evolution-hackers@gnome.org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers
> > ___
> > Evolution-hackers 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 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?

[Sankar P]

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 & 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] Evolution progress for 2.22

[Sankar P]

On Tue, 2007-12-04 at 19:09 +0530, Srinivasa Ragavan wrote:
> Hey Andre,
> >   * 233035 - support central deployment
> UAM should help to get this happen. 
> Sankar, isn't it?

Yes. It should. I would like to create an external setup tool which can
be launched without Evolution shell running that can create accounts. I
am a little unsure how the user specific information (username) will be
pushed though. Currently in design level.

> >   * make evo realize that it crashed when getting restarted
> > (mbarnes)
> Hmm, should be a overnight task IMO. But I think the requirements need
> to be frozen first. If you/mbarnes could blow it up on the wiki, it
> would be great.
> 
> >   * 347471 looks like already work in progress.
> >   * 335923 - lockdown support (i hope that federico is working
on
> > this?)
> Blame me, I couldn't spend time with Federico at Guadec. If I would
> have, I might have answered you with more concrete things.
> 

If we put all our accounts information in gconf (and lock it for normal
users), will that be not sufficient ? 

I guess I will get more information about this and integrate with my
easy-account-setup, if needed. 

> Anyways, thanks for bringing it (again) :)
> 
> -Srini
> 
> ___
> 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] EPlugin newbie query

[Sankar P]

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/ 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//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.

[Sankar P]

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

-- 
Sankar
Your greatest danger is letting the urgent things crowd out the
important. - Charles E. Hummel 

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Error storing summary.

[Sankar P]

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

[Sankar P]

On Thu, Jul 23, 2009 at 12:24 PM, Nirav Kumar 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 IS&T 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 IS&T. 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 IS&T
>> 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

[Sankar P]

he sqlite changes. This seems
> rather... wasteful? Kinda defeats the purpose of using sqlite (or any
> other database backend). The main problem with the older format is that
> it did not allow random-access, which means we really needed to load the
> whole thing into memory for a number of reasons:
>
>    1. each record being a different size requires sequential access
> from disk
>    2. can't sort by sender, subject, date (or whatever) until you have
> the entire summary in memory
>    3. doing lookups on message UIDs would be prohibitively slow from disk
>
> With a db backend, none of these problems exist any longer. Some Camel
> APIs would likely need to change in order to support taking advantage of
> this new feature, but it's something that needs to be done.
>

IIRC, For showing in message list, we already fetch only whatever
records are needed and do not load the full summary onto the memory.
For instance, if you have selected "Unread mail" in the QuickShow
combo box, only unread mails' summary items are loaded.

>
> These things seem like much bigger wins for Camel's (and, by extension,
> Evolution's) usability/maintainability than making Camel async and are
> also far more trivial to implement.
>
> Just some things to think 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] Moving from the single mbox file format for the local folders

[Sankar P]

>>> On 12/16/2009 at 01:16 AM, in message
<1260906365.615.858.ca...@linux-e1q4.site>, Chenthill 
wrote: 
> Hi fellow hackers!!
> I have been working for a while during last week on one the blockers
> in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 -
> 'Folder and summary mismatch error'(old one -
> https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact
> we have been working as a team to get the blockers down. I have not been
> able to reproduce the issue or yet find the exact problematic area.
> 
>   The mismatch in the frompos index in the folder summary may be caused
> by either a threading issue or a crash while storing the indexes. I am
> still investigating it to find the real cause.
> 
>   Looking at other issues such as, 
> https://bugzilla.gnome.org/show_bug.cgi?id=522433 - 'Fails opening mbox
>> 2GB', just got a thought if we could solve both the issues by,
> 
> Approach #1,
> migrating local storage from mbox to maildir format. With maildir I have
> heard about two issues,
> 
> * Not able to create subfolders under INBOX -
> https://bugzilla.gnome.org/show_bug.cgi?id=536240 .
> 
> Approach #2,
> Migrate from a single mbox file per folder to mbox per email. Srini
> mentioned an advantage that this would avoid the file renames that
> maildir does. I think this is much like how other remote providers in
> evo store the email.
> 
> I thought of bring this in this list to gather more opinions to choose
> the right one. The approach #2 seems a better one as we are choosing a
> way for storing the messages internally in evo. Are we missing to see
> anything while we choose the second one ? 
> 
> One advantage which I see with #1 is that its a standard way.
> 
> Thanks, Chenthill.
> 

Last I checked, maildir is known to have problems in windows.  

If so, Is Evo-on-Win a priority, etc. ? 

The mail storage part used by the GroupWise provider is same as what you 
suggest (afaics)
IIRC, I was told that it was derived from some cyrus storage style. 

Thanks.




--
Sankar 
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

[Sankar P]

>>> On 7/9/2010 at 09:44 PM, in message 
>>> <1278692045.6831.33.ca...@linux-e1q4.site>,
chen  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

[Sankar P]

>>> On 10/18/2010 at 07:01 PM, in message
<1287408711.3126.11.ca...@localhost.localdomain>, Matthew Barnes
 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

[Sankar P]

> 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?
> 



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



>>> 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)

[Sankar P]

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
>   
> YlFxYu

Re: [Evolution-hackers] GroupWise mail issue (Was: (no subject))

[Sankar P]

>>> On 2/16/2011 at 11:59 AM, in message <1297837796.2890.1.camel@zyxPad>, Milan
Crha  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

[Sankar P]

> 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