[Evolution-hackers] camel-db-summary changes merged to Trunk

2008-07-16 Thread Sankar
Hi ,

As many of you know, Srini and I were working on a branch
camel-db-summary (codenamed Madagascar).

This is now merged with trunk. Please see
http://svn.gnome.org/viewvc/evolution-data-server?view=revisionrevision=9125 

This adds a new dependency on sqlite. So, you need to have sqlite devel
packages installed. 

You will have to update evolution and evolution-exchange packages as
well.

As of now, evolution-exchange has some crashers connecting with the
exchange servers. 

Some of the quick-show items like (recent messages) does not work. 

Meta summary code is wiped out and hence new mails are not beagle
searcheable.

But, we promise we will fix them soon :-)


Any other feedback or issues, that you get, please ping us in
#evolution. 

I will be sending out a detailed description of what we have done and
what is pending, soon.

Thanks.

--
Sankar

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


Re: [Evolution-hackers] Unauthorised licence change to e-spinner.[ch]

2008-09-06 Thread Sankar
Hi Christian,

On Fri, 2008-09-05 at 15:16 +0200, Christian Persch wrote:
 Hi;
 
 The commit
 [http://svn.gnome.org/viewvc/evolution?limit_changes=0view=revisionrevision=36116]
  introduced a new copyright header for evolution/widgets/misc/e-spinner.[ch] 
 [http://svn.gnome.org/viewvc/evolution/trunk/widgets/misc/e-spinner.c?limit_changes=0r1=36116r2=36115pathrev=36116]
  above the old copyright header, in which it claims the code is
 a) now licensed under LGPL 2 and LGPL 3, and
 b) now Copyright (C) 1999-2008 Novell, Inc. (www.novell.com).
 
 Both of these claims are false.
 
 e-spinner.[ch] is derived from ephy-spinner.[ch] from Epiphany, and I
 hold the copyright on much of the code in it. It is licensed under the
 terms of the GPL 2+. As you can see from e-spinner.c's svn history
 [http://svn.gnome.org/viewvc/evolution/trunk/widgets/misc/e-spinner.c?view=log],
  this file was first checked into evolution in 2007, at which time it was 
 almost identical to ephy-spinner except for the rename of the namespace from 
 ephy to e. See the attached diff from ephy-spinner to today's e-spinner 
 after reversal of that rename to observe that the cumulative changes are 
 trivial (not to mention partially bogus), and even if they might justify a 
 2007-2008 novell copyright they certainly do not justify putting the novell 
 copyright notice above all other copyright holders and to even put a claim to 
 be an Author of it!
 
 Most importantly, I was not asked for permission to re-license this code
 to the LGPL 2 + LGPL 3; nor have I given such permission.
 


As there are many committers in Evolution sources, we sent out a common
mail to the desktop-devel and evolution-hackers mailing lists. Please
refer :

http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00065.html 

Also, I have been blogging about the license changes in planet gnome as
well, every time I make a change. http://psankar.blogspot.com/ 

 Please revert this unauthorised license change immediately.

I request you to wait till wednesday (10th September) , within which I
will be able to do some analysis and get back to you. We will revert to
the old state, if we cannot resolve the issue by then. 

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

--
Sankar

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


Re: [Evolution-hackers] Does evolution source still contains GPLv2 code?

2008-10-17 Thread Sankar
Hi,

On Fri, 2008-10-17 at 11:21 +0800, Harry Lu wrote:
 Srini,
 
   So in current state, Evolution is still combined by GPL and
 LGPLv2/LGPLv3 code, right? The target is  LGPLv3/LGPLv3 only, isn't it?
 

We have not completed the license change for all the files yet and hence
we had the COPYING file for all the three licenses.

The code was earlier in GPL.

We are in the process of changing every file in evolution to LGPL v2 /
LGPL V3

Thanks.

 Thanks,
 Harry
 
 On Fri, 2008-10-17 at 08:42 +0530, Srinivasa Ragavan wrote:
  Jeff,
  
  The COPYING (GPLv2) old license, COPYING.LGPLv2 COPYING.LGPLv3 are
  present in the tarballs. Evolution still has some files left  not moved
  to LGPLv2/LGPLv3. NEWs files might have been saying that some license
  changes code went in. Sorry for the confusion.
  
  -Srini.
  
  On Fri, 2008-10-17 at 11:01 +0800, Jeff Cai wrote:
   Hi
   
From the 2.24 tar package and svn trunk, I can still find the COPYING 
   file which says that it is GNU GENERAL PUBLIC LICENSE v2. But from 
   NEWS, it says Evolution source code license changed to LGPLv2  LGPLV3 
   (Sankar P).
   
   Sankar, I'm curious about whether evolution still contains GPLv2 code.
   
   Jeff
   
   ___
   Evolution-hackers mailing list
   Evolution-hackers@gnome.org
   http://mail.gnome.org/mailman/listinfo/evolution-hackers
  
  ___
  Evolution-hackers mailing list
  Evolution-hackers@gnome.org
  http://mail.gnome.org/mailman/listinfo/evolution-hackers

--
Sankar

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


Re: [Evolution-hackers] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead

2008-12-08 Thread Sankar
On Mon, 2008-12-08 at 18:59 +0100, Philip Van Hoof wrote:
 All metadata engines are nowadays working on a method to let them get
 their metadata fed by external applications.
 Such APIs come down to storing RDF triples. A RDF triple comes down to a
 URI, a property and a value.
 
 For example (in Turtle format, which is SparQL's inline format and the
 typical w3's RDF storage format):
 We'd like to make an Evolution plugin that does this for Tracker. 
 
 Obviously would it be as easy as letting software like Beagle become an
 implementer of prox's InsertRDFTriples to start supporting Beagle with
 the same code and Evolution plugin, this way.
 
 I just don't know which EPlugin hooks I should use. Iterating all
 accounts and foreach account all folders and foreach folder all
 CamelMessageInfo instances is trivial and I know how to do this.
 
 What I don't know is what reliable hooks are for:
 
   * Application started

org.gnome.evolution.shell.events:1.0 - es-event.c - 

sample plugin:
groupwise-account-setup/org-gnome-gw-account-setup.eplug.xml 


   * Account added

org.gnome.evolution.mail.config:1.0 

sample plugin:
groupwise-account-setup/org-gnome-gw-account-setup.eplug.xml 

For account-added: id = org.gnome.evolution.mail.config.accountDruid
For account-edited: id = org.gnome.evolution.mail.config.accountEditor

   * Account removed

You may have to write a new hook

   * Folder created
   * Folder deleted
   * Folder moved
   * Message deleted (expunged)
   * Message flagged for removal 
   * Message flagged as Read and as Unread
   * Message flagged (generic)
   * Message moved (ie. deleted + created)
   * New message received
 * Full message 
 * Just the ENVELOPE
 

If you try to update your metadata for every of the above operations, it
may be a overkill in terms of performance (and I believe more disk
access as well for updating your metadata store). You can add a new hook
while any change is made to the summary DB and listen to that. All the
above changes will have to eventually come to summary DB for them to be
valid.


However, I personally believe:

More and more applications are using sqlite (firefox and evolution my
two most used apps.)  So, it may be a better idea to directly map the
tables in an sqlite database into the search applications' data-store
(beagle, tracker etc.) instead of depending on the applications to give
the up-to-date data. 

When we implemented on-disk-summary for evolution summaries, we removed
the meta-summary code (used by beagle). We had to provide a way for
helping Beagle / Tracker to know of modified/new mails, so they could
(re)index these mails. Some suggested that we should add a DATETIME
field which contains the time-stamp of the time last modified/created
for each record. However, this in addition to bloating the database,
also does not provide any information about deleted records.

If, inside the sqlite db, if we have a special table comprising:
table-name,primary keys of records of last N records
modified/added,time-added; Any search application can make use of this
and update its lucene (or whatever) data ,  

It may not be the neatest approach, but what I want to say is : Instead
of depending on the enduser applications (which use sqlite) for giving
data, search applications, should be able to get the data from the db
itself. This also provides additional benefits like creating/updating
search indices when the machine is idle, instead of choking the
applications when they are running, etc.

My 0.2 EUROes ;-)

--
Sankar

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


Re: [Evolution-hackers] Reviewing imap_update_summary

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

2007-02-15 Thread Sankar P
On Thu, 2007-02-15 at 23:22 +0100, guenther wrote:
 On Tue, 2007-02-13 at 21:05 +0530, Sankar P wrote:
  On Fri, 2007-01-26 at 16:59 -0600, Matthew Martin wrote:
 
   I need to know where to put all
   the UI items for templates. There would need to be a save template,
   default new mail, and default reply items. I read some of the HIG and
   stuck them in there so I could write the code. Here's a link to the
   patches. 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)

2007-02-21 Thread 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)

2007-02-22 Thread 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)

2007-02-22 Thread 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 across the accounts. Like the ANNOUNCE
mail template that I described in my other mail.  And to send a mail
with in a defined template, just click on teh template, and choose
new-mail-from-this-template from a contextual menu and/or
file-new-mail-from-template which will list the templates. 


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

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


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

2007-04-13 Thread 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] Plugin and menu icons

2007-04-27 Thread 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

2007-06-06 Thread 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:
 
   http://OpenOSX.com/evolution.png
 
 
 
 Thanks,
 
 Jeshua Lacock, Owner
 http://OpenOSX.com
 phone: 877.240.1364
 
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Sankar

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


Re: [Evolution-hackers] Introduction and Questions

2007-06-07 Thread 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

2007-06-07 Thread 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 (the vast majority of E-mail clients totally suck at how
   they use the IMAP server, including Evolution indeed).
  
  Such a sweeping generalization !?
 
 Maybe, but I've seen quite a lot of their code, and they are indeed very
 badly programmed. Most of the custom Camel providers are in a very bad
 shape too, by the way.
 
 And ... camel-lite, camel upstream and its standard providers are also
 in a bad shape :(
 
  As you mentioned, IMAP (like any other technology) grows at a very
  high-speed. What you

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

2007-06-21 Thread 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] SpamBayes

2007-07-23 Thread 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

2007-08-09 Thread 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

2007-08-19 Thread 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

2007-08-20 Thread 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

2007-08-30 Thread 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

2007-10-12 Thread 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] Exchange MAPI Connector

2007-11-20 Thread 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?

2007-11-29 Thread 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 amp; to 
 inside HREF attributes again.  It's been broken this whole release.  I
 hate having to save the email to disk and reopen it from Firefox in
 order to properly use the links in some emails.
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Sankar P
Harver's Law: A drunken man's words are a sober man's thoughts

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


Re: [Evolution-hackers] EPlugin newbie query

2008-03-14 Thread 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/plugin-name folder.

I assume evolution is the folder where you have your evolution sources
built. 

Your plugin need to have its Makefile.am and follow autotools' logic.

1) Open the file configure.in your evolution source directory.
2) Search for plugins_standard and add your plugin-name to the list of
already existing plugin names. (like 
3) Search for plugins/external-editor/Makefile and add your plugin
name as plugins/your-plugin-name/Makefile

4) Now run autogen with the argument --enable-plugins=all along with
all other arguments that you have used earlier.

5) Run make install from your plugin directory. You should have your
plugin installed.

 May I know how to use this option?
 
 Johan J.N
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
-- 
Sankar P

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


Re: [Evolution-hackers] Error storing summary.

2008-05-12 Thread 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

2009-07-23 Thread Sankar P
On Thu, Jul 23, 2009 at 12:24 PM, Nirav Kumarkni...@novell.com wrote:
 Hi Andre,
 Migrating Wiki to live.gnome.org/evolution may be difficult with the
 high data content that evolution wiki holds.

I don't see a high data content. There are Camel docs, plugin docs,
some design docs about shell and threading, most of which will have to
change anyway, soon. And most of the other links originating from the
go-evolution home page points to obsolete contents. There are some
test cases, but iirc they are stored in Novell testopia already.

 I would believe that installing captcha and updating drupple should be
 able to provide the desired results.I am working with Novell IST and
 hope to have something positive in next few days.


These two are the problems at the moment. But by moving to
live.gnome.org, there are other benefits like:

- we align more with the rest of the Gnome projects
- one place to search docs for all projects and easy to link to docs
of other project pages, say libsoup.
- no need to create yet-another-new-account to edit evo project pages.
anyone with a gnome account can edit pages.

and above all,

- Gnome sysadmins are easily reachable for non-Novell folks to report
and rectify any problems, than Novell IST. There will be a single
point of contact for admin related issues.

If all these does not convince you, you can save dollars on the
storage space for the site ;-) . So imho, it is definitely worth
moving to live.gnome.org .

 Regards
 Nirav
 On Thu, 2009-07-23 at 12:06 +0530, Chenthill wrote:
 Am including nirav in the thread. He is working on with the novell IST
 to get the required rights. He would be able to provide more details..

 Thanks, Chenthill.
 On Mon, 2009-07-13 at 11:06 +0200, Andre Klapper wrote:
  Am Sonntag, den 12.07.2009, 21:31 -0400 schrieb Matthew Barnes:
   I don't know how feasible this is, but what do you guys think about
   eventually migrating the wiki to live.gnome.org/evolution.
 
  I am all for it.
 
   I have no idea who has admin rights to the wiki
 
  According to Parag Srini has sysop rights.
 
  andre




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




-- 
Sankar P
http://psankar.blogspot.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel Manifesto

2009-11-21 Thread Sankar P
 about...


I tend to agree with Fejj on this and I am big fan of threads. But I
no longer work on evo and knowing Matthew  I believe he knows what is
the best. All the best :-)

-- 
Sankar P
http://psankar.blogspot.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] evolution-kolab: Lifting the veil

2010-07-09 Thread Sankar P
 On 7/9/2010 at 09:44 PM, in message 
 1278692045.6831.33.ca...@linux-e1q4.site,
chen pchenth...@novell.com wrote: 
 On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote:
  On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote:
If Evolution staff will be willing to host our project sources within
Evo git repo, we'll happily transfer our stuff there as soon as we
have a first preview ready.
   
 Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be
   great to have you working in the same git repo IMHO [ not that it's my
   decision of course - I defer to Matthew/Chen etc. ;-]
  
  
  Certainly aim for hosting your project on git.gnome.org, but I'd still
  prefer it be split into a separate evolution-kolab repository similar to
  evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm
  told).  It just keeps things more modular and it keeps us honest: our
  public APIs -have- to be complete since external projects don't have
  access to private in-tree APIs.  The separation is not meant to be a
  barrier between you and us, just an implementation detail.
 While thinking about this, I just got a thought of why not a,
 evolution-collab-backends package which can hold all the eds
 collborative backends (that provides mail+calendar+address-book) such as
 mapi, exchange, groupwise with sufficient configuration options to
 choose what to compile ? This would help in making the api changes to
 all backends and keep external backends connected. 
 
 I support maintaining the backend code in a separate package though. Its
 easier to provide updates to the backends if its not part of eds
 at-least with some distros (at-least with suse as I use it).



More modules translate to more problems trying to build things. Oh I need to 
git clone another 10 modules. In my opinion, we should just follow linux kernel 
filesystems style (all under one tree). There can be any number of backends, 
but we can use sane config options to build only interested backends (for 
instance someone working on RHT may not bother about GW etc.) But for someone 
who wants to build evo with all backends, it is just one 'git clone' that he 
needs to do. 

Also, during release time, more modules contribute to more work for the 
maintainer(s).  Changes made in core may not reflect in some low priority 
backends, if they are kept out of the tree. (oh that out-of-tree Scalix backend 
is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types)

However,  I am a little out of touch with the things and so I trust 
Chen/Matthew 's decisions as they know the current state. Just my 2 cents. 

Sankar
 
 - Chenthill.
  
  The process for obtaining a gnome.org account is here:
  
  http://live.gnome.org/NewAccounts 
  
  Each of your developers should apply for their own account, but I would
  suggest waiting to do this until after you have a working public beta,
  as you'll have more credibility to the gnome.org admins then (which is
  not us!).
  
  Once you have your gnome.org accounts, you can clone your git repository
  on git.gnome.org by following the procedure here:
  
  http://live.gnome.org/Git/NewRepository 
  
  Hope this helps.
  
  
  ___
  evolution-hackers mailing list
  evolution-hackers@gnome.org 
  To change your list options or unsubscribe, visit ...
  http://mail.gnome.org/mailman/listinfo/evolution-hackers 
 
 
 
 ___
 evolution-hackers mailing list
 evolution-hackers@gnome.org 
 To change your list options or unsubscribe, visit ...
 http://mail.gnome.org/mailman/listinfo/evolution-hackers 
 

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Merging the collaboration providers in a single package

2010-10-18 Thread Sankar P
 On 10/18/2010 at 07:01 PM, in message
1287408711.3126.11.ca...@localhost.localdomain, Matthew Barnes
mbar...@redhat.com wrote: 
 On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
  The other solution was to maintain all exchange providers in a single
  package, merging evolution-exchange, evolution-ews and evolution-mapi
  into a single package. Other collaboration providers like
  evolution-groupwise and evolution-kolab (yet to be upstreamed) will
  remain as separate packages.
 
 If we -have- to glob providers together I would prefer the alternate
 solution: merge all the Exchange providers into one git module, break
 GroupWise out from E-D-S into it's own git module, and leave the rest
 alone.
 
 This is not unlike the recent gnome-games debate on desktop-devel-list,
 except that we already have shared libraries for the common parts with
 fairly stable APIs (libebook, libecal, etc.).
 
 Jon's comments on the gnome-games issue reflect my own for this one:
 http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html 
 
 

I prefer not to have every provider in its own module.  If we make changes in 
the baseclass, it will be ignored and won't go into unmaintained providers. 
More providers translates to more work for packagers downstream and also during 
the release time for maintainers as well, with not much benefits.  

Just my 2 cents. 

Sankar

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Merging the collaboration providers in a single package

2010-10-19 Thread 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?
 

Packager Hat

Why ? We wont. We will just get one tarball update when released and build that 
with whatever configure options that suits our distro.  We won't attempt to 
divide further. 

Like for instance, for kernel, we have only: kernel-pae/x86_64.rpm and no 
kernel-fs-ext3.rpm, kernel-fs-btrfs.rpm etc.  All filesystems are inside the 
kernel.rpm

/Packager Hat

 Just my 2 cents.
 I agree. I would not term as un-maintained providers. If they are really
 un-maintained, which means many bugs exist and people are not able to
 use it, it has to be pruned at some point.

 But certainly I see advantages to have the providers in a single package
 which would help us adapt to the API changes well, translations could be
 shared, packagers can look for updates for one package and maintainers
 would have less burden in releasing many packages.
 
 Turning it around the other way, if a change in the globbed package
 means nothing to the provider I'm using or interested in, what's in it
 for me to update the package? :-)
 

None. Agreed.  

 If a module is maintained, the API changes will eventually get there.
 Besides, you shouldn't be changing the base API that often anyway ;-)

Agreed.  Ideally ;-)

Sankar

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] (no subject)

2011-02-15 Thread 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
   
 YlFxYupes7MwgxVlUjAheLjYJ2qW/7lomKq+ZXr1

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

2011-02-15 Thread Sankar P
 On 2/16/2011 at 11:59 AM, in message 1297837796.2890.1.camel@zyxPad, Milan
Crha mc...@redhat.com wrote: 
 On Tue, 2011-02-15 at 23:16 -0700, Sankar P wrote:
  Your last few mails are displayed as I have attached below in a
  non-open mail client that I use (GroupWise).
 
   Hi,
 I guess it's the X-Face header doing trouble for GroupWise.

Probably. Because your mail comes fine. 

Sankar

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Cache encryption

2011-03-04 Thread 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


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

2011-12-04 Thread 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
dw...@infradead.org wrote: 
 We have at least three mail protocols now which are delta-based. That
 is, you have a bookmark, 'sync key' or timestamp which represents what
 the server *last* told you about a given folder. You say to the server
 what changed since XXX, and get back a list of added/removed/changed
 messages along with a *new* timestamp YYY.
 
 It's a very efficient way to handle mailbox access, and it's used by at
 least ActiveSync, EWS and IMAP+QRESYNC. In the Exchange protocols it's
 called 'SyncState' or 'SyncKey', and in IMAP it's the HIGHESTMODSEQ.
 (It's never *actually* a timestamp, since wall-clock time is a PITA. But
 it's easy to *think* of it as as timestamp; the modification time on the
 folder).
 
 The problem is, we need to handle these updates *atomically*. If we
 store the new timestamp before the changed messages, and we crash in the
 middle of doing so, then we might miss out forever on the messages in
 question. We'd restart, go to the server and say what happened since
 YYY and we never get told *again* about the messages which came in
 between time XXX and time YYY, that we didn't manage to fetch.
 
 And if you do it the other way round and store the changed messages
 first, and crash before you store the new timestamp, you get similar
 issues (cf. bug 664637).
 
 I'm not sure how to fix it. Looking at EWS first, since that's where we
 noticed it, I pondered removing the camel_folder_summary_save_to_db()
 call from the camel_ews_utils_sync_{created,updated,deleted}_items()
 helper functions, so it happens just *once* at the end of the loop in
 ews_refresh_info_sync() and commits all the changes at once. But just
 deferring the camel_folder_summary bits isn't enough, is it? The
 individual message_infos will have a lifetime of their own, and even
 *internally*, camel_folder_summary_save_to_db() doesn't actually write
 things out atomically using transactions in sqlite... does it?
 
 Any suggestions or insight would be gratefully received...
 
 -- 
 dwmw2
 


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Vacuum folders.db on expunge?

2012-01-18 Thread Sankar P
 On 1/18/2012 at 09:17 PM, in message
1326901656.25967.14.camel@localhost.localdomain, Matthew Barnes
mbar...@redhat.com wrote: 
 I still find myself occasionally pointing users to the little shell
 script Srini wrote some years ago to vacuum out all your folders.db.
 Since moving to XDG base dirs I've kept an updated version of it here:
 
 http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb 
 
 Usually after running the script, users report that Evolution feels fast
 and responsive again.
 
 Evolution really needs to be doing this on its own periodically, but I
 would rather the user not be aware of it.  So no new pop-up dialogs or
 info bars or anything like that.
 
 I thought a natural place to tie a database cleansing into would be a
 folder expunge (and also File - Empty Trash), something most users do
 every now and then already -- or at least something we could instruct
 them to do directly within Evolution.
 
 Plus, users are already accustomed to a short delay when emptying trash,
 so a little extra delay there should be pretty inconspicuous.
 
 Thoughts?
 

sqlite is used  by not just Evo. But by other applications like Firefox, 
chromium, too.

In openSUSE we found a solution 
http://gitorious.org/opensuse/vacuumizer/blobs/master/vacuumizer to do this via 
a script.

May be the disros can run this script once a month on gdm logging in, so that 
all applications can be benefitted.

Sankar

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Is it worth customizing the IMAP headers to fetch?

2012-12-16 Thread 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