[Evolution-hackers] unsubscribing to evolution-mail-maintainers
Can anyone tell me how to go about getting unsubscribed from the evolution-mail-maintainers list? Thanks, Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] Support in Tracker for ultra-new Evolution installs that use SQLite for the summary format
hi philip, short comment (the tablet is not the best device to review patches): can we call this module evolution224 and keep also the old module? we could choose between one or other with a flag in compilation time (the distributions will choose the correct for them) regards, Ivan On 12/11/08, Philip Van Hoof s...@pvanhoof.be wrote: This patch makes ultra-new Evolution installs work again with Tracker. There's one problem and that is that the query will only find E-mails in the INBOX folder. You can easily find the Query and figure out what the problem is: The design that Carlos made assumes that for each folder there's a summary file. In the new Evolution cache format there's just one folders.db for each account. I could do a generated UNION select after first doing select * from folders on folders.db and then generating a query that includes all folders. I just have not done this for now and instead I'm just using INBOX and I'm neglecting the other folders. This is NOT the same as the proposal that I am doing at (a). This is instead a ad-hoc solution for the new situation (Evolution using SQLite for the summaries). I find this solution rather nasty, to be honest. (a) http://live.gnome.org/Evolution/Metadata For Carlos: I have also fixed a serious problem in evolution-pop.c, which is by the way unaffected by Evolution's changes (and works, if you just apply the patch that I included in this larger patch). The POP support's get_message_metadata was not returning metadata. This was crashing my tracker-indexer (as seemingly my compiler was putting return 0x2 where the return was omitted, and the memory I have at 0x2 didn't dereference TrackerModuleMetadata's members very well). Please review and/or rework the patch. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] Support in Tracker for ultra-new Evolution installs that use SQLite for the summary format
Hi, philip How about to open folders.db in readonly mode? I just check sqlite's API. sqlite3_open_v2 support a para with readonly flag On 2008ǯ12·î12Æü 00:34, Philip Van Hoof wrote: This patch makes ultra-new Evolution installs work again with Tracker. There's one problem and that is that the query will only find E-mails in the INBOX folder. You can easily find the Query and figure out what the problem is: The design that Carlos made assumes that for each folder there's a summary file. In the new Evolution cache format there's just one folders.db for each account. I could do a generated UNION select after first doing select * from folders on folders.db and then generating a query that includes all folders. I just have not done this for now and instead I'm just using INBOX and I'm neglecting the other folders. This is NOT the same as the proposal that I am doing at (a). This is instead a ad-hoc solution for the new situation (Evolution using SQLite for the summaries). I find this solution rather nasty, to be honest. (a) http://live.gnome.org/Evolution/Metadata For Carlos: I have also fixed a serious problem in evolution-pop.c, which is by the way unaffected by Evolution's changes (and works, if you just apply the patch that I included in this larger patch). The POP support's get_message_metadata was not returning metadata. This was crashing my tracker-indexer (as seemingly my compiler was putting return 0x2 where the return was omitted, and the memory I have at 0x2 didn't dereference TrackerModuleMetadata's members very well). Please review and/or rework the patch. ___ tracker-list mailing list tracker-l...@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
2008/12/10 Michael Meeks michael.me...@novell.com Hi Philip, On Tue, 2008-12-09 at 19:59 +0100, Philip Van Hoof wrote: http://live.gnome.org/Evolution/Metadata For early visitors of that page, refresh because I have added/changed quite a lot of it already. Looks really good. But I have some comments to attach and some bike sheds to paint :-) Comments on the proposal below. The only thing that I don't quite understand (the perennial problem with asynchronous interfaces), is the memory issue: it seems we need to store all Unset information on deleted mails somewhere [ unless you are a womble like me that keeps ~all mail forever ;-]. Is it that big a problem? I mean if you store 100,000 uris of avg. length 50 chars you will have a file about 5mb... One needs only keep an absolute minimum amount of metadata around. That aside here are my comments: * I had personally expected something more like a harvesting API, but what you present is more like a metadata writing API. Much like the set of writing methods in http://xesam.org/main/XesamMetadataAPI. This may just be a matter of taste though. * If we are talking a harvesting metaphor (which we may not be) then it seems wrong to imply in the methods that Evo is writing the data and not just sending it * I thought Tracker needed a service type to select the right table. Of course we know we are dealing with emails here, but the API fails to generalize. * Timestamps are not mandatory in the protocol. The receiver will have to parse the payload to extract a timestamp (which is not guaranteed to be there in the first place). Without a timestamp a payload is meaningless * Is there any form of sorting mandated by the SetMany method? Fx sorting subjects by mtime? * About the Set method. What happens to predicates set on the subject that are not in the 'predicates' arg? Are they kept or deleted? Or to rephrase the question do you overwrite the entire set of metadata for the subject? I have cooked together something that should work as a generic harvesting API here: http://xesam.org/main/Drafts/XesamPMH. It should address all of the points I raise here too. -- Cheers, Mikkel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
2008/12/13 Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com 2008/12/10 Michael Meeks michael.me...@novell.com Hi Philip, On Tue, 2008-12-09 at 19:59 +0100, Philip Van Hoof wrote: http://live.gnome.org/Evolution/Metadata For early visitors of that page, refresh because I have added/changed quite a lot of it already. Looks really good. But I have some comments to attach and some bike sheds to paint :-) Comments on the proposal below. The only thing that I don't quite understand (the perennial problem with asynchronous interfaces), is the memory issue: it seems we need to store all Unset information on deleted mails somewhere [ unless you are a womble like me that keeps ~all mail forever ;-]. Is it that big a problem? I mean if you store 100,000 uris of avg. length 50 chars you will have a file about 5mb... One needs only keep an absolute minimum amount of metadata around. That aside here are my comments: * I had personally expected something more like a harvesting API, but what you present is more like a metadata writing API. Much like the set of writing methods in http://xesam.org/main/XesamMetadataAPI. This may just be a matter of taste though. * If we are talking a harvesting metaphor (which we may not be) then it seems wrong to imply in the methods that Evo is writing the data and not just sending it * I thought Tracker needed a service type to select the right table. Of course we know we are dealing with emails here, but the API fails to generalize. * Timestamps are not mandatory in the protocol. The receiver will have to parse the payload to extract a timestamp (which is not guaranteed to be there in the first place). Without a timestamp a payload is meaningless * Is there any form of sorting mandated by the SetMany method? Fx sorting subjects by mtime? * About the Set method. What happens to predicates set on the subject that are not in the 'predicates' arg? Are they kept or deleted? Or to rephrase the question do you overwrite the entire set of metadata for the subject? I have cooked together something that should work as a generic harvesting API here: http://xesam.org/main/Drafts/XesamPMH. It should address all of the points I raise here too. Apart from these items I still find that there are other issues with the proposed API at: http://live.gnome.org/Evolution/Metadata * How is last_checkout calculated by the client? The local system time of the client wont do as there might be a time skew compared to the server (DBus might go over tcp). This means that the timestamp must be extracted from the received emails, this is not guaranteed to be there by the spec though. * If each mail is not guaranteed to have a timestamp how can the registrar resume an update if it was shut down when it was 90% through 100,000 emails? Ofcourse if each email _must_ have nmo:receivedDate (or some other timestamp) then these two items are non-issues. I would have prefered such crucial information to be in the API though... That said I think the idea with the CleanUp method is great! :-) -- Cheers, Mikkel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Viewer for file-stored E-Mails
Hi, I usually store important E-Mails one-by-one in files, thus I can backup these information easily. I am in the process of switching from Windows/Outlook to Linux/Evolution. In Evolution the only Save as format is normal Unix mbox. But in Linux I cannot view these files just by selecting them in a file explorer. Am I missing something? I just can't find a tool which just lets me view an mbox file. Of course I can re-import the file in Evolution. But this isn't my intention. Any help for me? Thanks Michael ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Adding the created and modified columns to summary tables
I have created a bug for this:
http://bugzilla.gnome.org/show_bug.cgi?id=565082
I have attached a cleaner version of the patch too.
Please comment and/or review
On Wed, 2008-12-17 at 12:41 +0100, Philip Van Hoof wrote:
Hi there,
This patch deals with converting the old SQLite tables to a new format
and adds created and modified.
It's a first rough idea, so please let me know what I should change.
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
Index: camel/camel-db.c
===
--- camel/camel-db.c (revision 9841)
+++ camel/camel-db.c (working copy)
@@ -767,15 +767,137 @@
return ((camel_db_command (cdb, query, ex)));
}
+static int
+camel_db_migrate_folder_prepare (CamelDB *cdb, const char *folder_name, gint version, CamelException *ex)
+{
+ int ret = 0;
+ sqlite3_stmt *stmt = NULL;
+ char *table_creation_query;
+
+ /* Migration stage one: storing the old data */
+
+ if (version 1) {
+ table_creation_query = sqlite3_mprintf (DROP TABLE 'temp_%q', folder_name);
+ stmt = NULL;
+ ret = sqlite3_prepare_v2 (cdb-db, table_creation_query, -1, stmt, NULL);
+ if (ret == SQLITE_OK)
+ ret = sqlite3_step (stmt);
+ sqlite3_finalize (stmt);
+ sqlite3_free (table_creation_query);
+
+ table_creation_query = sqlite3_mprintf (CREATE TEMP TABLE IF NOT EXISTS 'temp_%q' ( uid TEXT PRIMARY KEY , flags INTEGER , msg_type INTEGER , read INTEGER , deleted INTEGER , replied INTEGER , important INTEGER , junk INTEGER , attachment INTEGER , msg_security INTEGER , size INTEGER , dsent NUMERIC , dreceived NUMERIC , subject TEXT , mail_from TEXT , mail_to TEXT , mail_cc TEXT , mlist TEXT , followup_flag TEXT , followup_completed_on TEXT , followup_due_by TEXT , part TEXT , labels TEXT , usertags TEXT , cinfo TEXT , bdata TEXT, created TEXT, modified TEXT ), folder_name);
+ stmt = NULL;
+ ret = sqlite3_prepare_v2 (cdb-db, table_creation_query, -1, stmt, NULL);
+ if (ret == SQLITE_OK)
+ ret = sqlite3_step (stmt);
+ sqlite3_finalize (stmt);
+ sqlite3_free (table_creation_query);
+
+ table_creation_query = sqlite3_mprintf (INSERT INTO 'temp_%q' SELECT uid , flags , msg_type , read , deleted , replied , important , junk , attachment , msg_security , size , dsent , dreceived , subject , mail_from , mail_to , mail_cc , mlist , followup_flag , followup_completed_on , followup_due_by , part , labels , usertags , cinfo , bdata , strftime(\%%s\, 'now'), strftime(\%%s\, 'now') FROM %Q, folder_name, folder_name);
+ stmt = NULL;
+ ret = sqlite3_prepare_v2 (cdb-db, table_creation_query, -1, stmt, NULL);
+ if (ret == SQLITE_OK)
+ ret = sqlite3_step (stmt);
+ sqlite3_finalize (stmt);
+ sqlite3_free (table_creation_query);
+
+ table_creation_query = sqlite3_mprintf (DROP TABLE %Q, folder_name);
+ stmt = NULL;
+ ret = sqlite3_prepare_v2 (cdb-db, table_creation_query, -1, stmt, NULL);
+ if (ret == SQLITE_OK)
+ ret = sqlite3_step (stmt);
+ sqlite3_finalize (stmt);
+ sqlite3_free (table_creation_query);
+ }
+
+ /* Add later version migrations here */
+
+ return ret;
+}
+
+static int
+camel_db_migrate_folder_recreate (CamelDB *cdb, const char *folder_name, gint version, CamelException *ex)
+{
+ int ret = 0;
+ char *table_creation_query;
+
+ /* Migration stage two: writing back the old data */
+
+ if (version 1) {
+ table_creation_query = sqlite3_mprintf (INSERT INTO %Q SELECT uid , flags , msg_type , read , deleted , replied , important , junk , attachment , msg_security , size , dsent , dreceived , subject , mail_from , mail_to , mail_cc , mlist , followup_flag , followup_completed_on , followup_due_by , part , labels , usertags , cinfo , bdata, created, modified FROM 'temp_%q', folder_name, folder_name);
+ ret = camel_db_add_to_transaction (cdb, table_creation_query, ex);
+ sqlite3_free (table_creation_query);
+
+ table_creation_query = sqlite3_mprintf (DROP TABLE 'temp_%q', folder_name);
+ ret = camel_db_add_to_transaction (cdb, table_creation_query, ex);
+ sqlite3_free (table_creation_query);
+ }
+
+ /* Add later version migrations here */
+
+ return ret;
+}
+
+static int
+camel_db_write_folder_version (CamelDB *cdb, const char *folder_name, int old_version, CamelException *ex)
+{
+ int ret = 0;
+ char *version_creation_query;
+ char *version_insert_query;
+
+ version_creation_query = sqlite3_mprintf (CREATE TABLE IF NOT EXISTS '%q_version' ( version TEXT ), folder_name);
+
+ if (old_version == -1)
+ version_insert_query = sqlite3_mprintf (INSERT INTO '%q_version' VALUES ('1'), folder_name);
+ else
+ version_insert_query = sqlite3_mprintf (UPDATE '%q_version' SET version='1', folder_name);
+
+ ret = camel_db_add_to_transaction (cdb, version_creation_query, ex);
+ ret = camel_db_add_to_transaction (cdb, version_insert_query, ex);
+
+ sqlite3_free (version_creation_query);
+ sqlite3_free (version_insert_query);
+
+ return ret;
+}
+
[Evolution-hackers] Metadata and Evolution
Hi guys (evos and trakkies), I will be tracking a patch that is related to the Evolution metadata proposal (x) at this bug in GNOME's bugzilla. http://bugzilla.gnome.org/show_bug.cgi?id=565082 It contains a patch that Evolution's most recent Camel needs in order to support the EPlugin that will be written to implement (x). #x http://live.gnome.org/Evolution/Metadata -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Crossover projects (Was: Metadata and Evolution)
Hi evos and trakkies, On Fri, 2008-12-19 at 10:55 +0100, Philip Van Hoof wrote: I will be tracking a patch that is related to the Evolution metadata proposal (x) at this bug in GNOME's bugzilla. http://bugzilla.gnome.org/show_bug.cgi?id=565082 It contains a patch that Evolution's most recent Camel needs in order to support the EPlugin that will be written to implement (x). #x http://live.gnome.org/Evolution/Metadata I attached a patch that illustrates the skeleton of the project that will implement support for this Metadata format in Tracker, as a EPlugin that'll be installed by the Tracker package (at least initially). This is a bug for tracking the progression on this. http://bugzilla.gnome.org/show_bug.cgi?id=565091 ps. Bug# 565082 (above) will of course block Bug #565091. It's also already marked as such. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be eplugin-metadata-tracker.diff.gz Description: GNU Zip compressed data ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Viewer for file-stored E-Mails
Hi Michael, Michael Städler wrote: I usually store important E-Mails one-by-one in files, thus I can backup these information easily. I am in the process of switching from Windows/Outlook to Linux/Evolution. In Evolution the only Save as format is normal Unix mbox. But in Linux I cannot view these files just by selecting them in a file explorer. Am I missing something? I just can't find a tool which just lets me view an mbox file. Of course I can re-import the file in Evolution. But this isn't my intention. Any help for me? As you probably know, the mbox format is flat text. For casual reading and searching you can use pretty much any text editor. However, I know that's not what you're asking for. I don't know of any desktop program that views mbox files, but mutt on the command line will do it with the -f switch. --Pat ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
