Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS

2011-03-10 Thread Matthew Barnes
On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote:
 do not forget that the DB cache is compiled conditionally, because some
 distros do not ship libdb. Using SQLite for this was mentioned months
 ago, only no-one got time to actually do it, so go for it.

Also, as far as I know there is still licensing issues between Berkeley
DB's Sleepcat license and [L]GPL, which is how libebackend was born.

https://bugzilla.gnome.org/show_bug.cgi?id=465374

I'm +1 on dumping Berkeley DB.


 Only think of two things:
 - using binary storage for this kind of data is bad for cases where
   the binary file breaks, either due to an update/downgrade of the
   library providing access to it, or just by a crash. It's not so hot
   with camel as SQLite has there only summary data, but if you want to
   store also real data in it, then it can be a problem. There are people
   having issues recovering their data from addressbook storage already,
   but if you are going to do any change on it, then it would be good to
   think of that from the beginning. It would be good to store raw vCards
   in some plain text file(s) which will be indexed by SQLite summary.
   This plain text file(s) will be then easy to import to evolution if
   something goes wrong, and with erasing SQLite file user will not
   loose any valuable data. (I'm thinking of a flat maildir approach
   here.)

Milan raises a good point about binary formats versus text.  Would be
good for the raw data to remain human readable.

Okay, this might be a long shot but I'm gonna throw it out there anyway:
would it make sense to look at using Xapian to index a directory of raw
vCards?

We've been talking about moving to notmuch [1] for mail indexing, and
notmuch is built on Xapian.  Trying out Xapian for address books might
be a good test drive for using it with mail.

The catch is, Xapian is written in C++.  So we'd likely have to hand
write our own GObject bindings for it in C.  That's what makes it a long
shot.  But we could look to notmuch even WebKit/GTK+ for examples of
binding C++ to C.  My C++ is rusty but I still have my Stroustrup text
book.


[1] http://notmuchmail.org/

___
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] Handy GObject debugging trick

2011-03-10 Thread David Woodhouse
On Wed, 2011-03-09 at 18:20 -0500, Matthew Barnes wrote:
 
 4. Read the stats to see how badly $MY_APPLICATION is leaking objects.

This is useful; thanks. Although we really *do* need to see it at
runtime. I played a little with Colin's LD_PRELOAD hack and Evolution:

CamelDataCache | created 214 | destroyed 0
CamelEwsFolder | created 30 | destroyed 0
CamelEwsSummary | created 30 | destroyed 0
CamelFolderSearch | created 232 | destroyed 0
CamelIMAPXFolder | created 183 | destroyed 0
CamelIMAPXSummary | created 183 | destroyed 0

Are we not *ever* closing a folder, after the UI has visited it once?

No wonder Evolution tends to grow until it's eating all the memory in my
system... :)

-- 
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] Handy GObject debugging trick

2011-03-10 Thread Milan Crha
On Thu, 2011-03-10 at 13:42 +, David Woodhouse wrote:
 Are we not *ever* closing a folder, after the UI has visited it once?

Hi,
CamelStore keeps list of opened folders in its bag-container, and
because there are caches of CamelStore-s which are not freed properly,
then neither folders are freed as ought to be. Did you ever notice a
flash in the folder tree when you change something in the account
preferences, but those changes were not propagated till next start? I
believe it's a side-effect of such CamelStore caches issue in evo
itself.

 No wonder Evolution tends to grow until it's eating all the memory in my
 system... :)

Well, it depends. There were some bugs fixed already (in 2.91.91), but
many are still there which no-one is aware of, I'm sure of that.

Two most significant I recall right now:
a) any attachments shown in the message preview were never freed,
together with its content - so with large attachments memory usage could
grow pretty quickly
b) the templates plugin used to leak folder infos when building menu
options for itself. It's not much leaking in a byte-size, but as the
menu is regenerated on each click/move/change in the message list, then
this can grow in time also quite quickly.

Thinking of Matt's change, I wrote something similar recently too, not
that sophisticated, and it did slightly different things too, but it did
what I wanted from it as well. Mine change was for pointer tracking.
Simple routines to track and untrack concrete pointer (usually track a
pointer in its init method and untrack it in its finalize method), and
list left pointers when exiting the application. I thought I'll add it
to Camel, but then I realized it's not about Camel only, so it could
come to e-data-server-util.h/.c, but then I couldn't decide, so I simply
dropped it. Maybe it would be useful for debugging purposes too. It was
for me. 
Bye,
Milan

___
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] Headers

2011-03-10 Thread Richard Bromwich
I really think Evolution is great mail program but its lacking a very 
important feature for someone who travels.


The ability to just download message headers, and then being able to 
download only the messages you want to read at the moment

and leave the rest on the server or delete the junk without downloading.

Hope to see this feature before too long.
Thanks Richard

I now have to use thunderbird  when I travel
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers