notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
/* database.cc - The database interfaces of the notmuch mail library
|
|
|
|
*
|
|
|
|
* Copyright © 2009 Carl Worth
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program. If not, see http://www.gnu.org/licenses/ .
|
|
|
|
*
|
|
|
|
* Author: Carl Worth <cworth@cworth.org>
|
|
|
|
*/
|
|
|
|
|
2009-10-21 06:03:30 +02:00
|
|
|
#include "database-private.h"
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
#include <iostream>
|
|
|
|
|
|
|
|
#include <xapian.h>
|
|
|
|
|
2009-10-20 21:49:32 +02:00
|
|
|
#include <glib.h> /* g_strdup_printf, g_free, GPtrArray, GHashTable */
|
2009-10-19 21:54:40 +02:00
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
using namespace std;
|
|
|
|
|
2009-10-22 01:12:53 +02:00
|
|
|
const char *
|
|
|
|
notmuch_status_to_string (notmuch_status_t status)
|
|
|
|
{
|
|
|
|
switch (status) {
|
|
|
|
case NOTMUCH_STATUS_SUCCESS:
|
|
|
|
return "No error occurred";
|
|
|
|
case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
|
|
|
|
return "A Xapian exception occurred";
|
|
|
|
case NOTMUCH_STATUS_FILE_NOT_EMAIL:
|
|
|
|
return "File is not an email";
|
|
|
|
case NOTMUCH_STATUS_NULL_POINTER:
|
|
|
|
return "Erroneous NULL pointer";
|
|
|
|
case NOTMUCH_STATUS_TAG_TOO_LONG:
|
|
|
|
return "Tag value is too long";
|
|
|
|
default:
|
|
|
|
case NOTMUCH_STATUS_LAST_STATUS:
|
|
|
|
return "Unknown error status value";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
/* "128 bits of thread-id ought to be enough for anybody" */
|
|
|
|
#define NOTMUCH_THREAD_ID_BITS 128
|
|
|
|
#define NOTMUCH_THREAD_ID_DIGITS (NOTMUCH_THREAD_ID_BITS / 4)
|
|
|
|
typedef struct _thread_id {
|
|
|
|
char str[NOTMUCH_THREAD_ID_DIGITS + 1];
|
|
|
|
} thread_id_t;
|
|
|
|
|
|
|
|
static void
|
|
|
|
thread_id_generate (thread_id_t *thread_id)
|
|
|
|
{
|
|
|
|
static int seeded = 0;
|
|
|
|
FILE *dev_random;
|
|
|
|
uint32_t value;
|
|
|
|
char *s;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (! seeded) {
|
|
|
|
dev_random = fopen ("/dev/random", "r");
|
|
|
|
if (dev_random == NULL) {
|
|
|
|
srand (time (NULL));
|
|
|
|
} else {
|
|
|
|
fread ((void *) &value, sizeof (value), 1, dev_random);
|
|
|
|
srand (value);
|
|
|
|
fclose (dev_random);
|
|
|
|
}
|
|
|
|
seeded = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
s = thread_id->str;
|
|
|
|
for (i = 0; i < NOTMUCH_THREAD_ID_DIGITS; i += 8) {
|
|
|
|
value = rand ();
|
|
|
|
sprintf (s, "%08x", value);
|
|
|
|
s += 8;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-22 00:53:38 +02:00
|
|
|
/* XXX: We should drop this function and convert all callers to call
|
|
|
|
* _notmuch_message_add_term instead. */
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
static void
|
|
|
|
add_term (Xapian::Document doc,
|
|
|
|
const char *prefix_name,
|
|
|
|
const char *value)
|
|
|
|
{
|
|
|
|
const char *prefix;
|
|
|
|
char *term;
|
|
|
|
|
|
|
|
if (value == NULL)
|
|
|
|
return;
|
|
|
|
|
2009-10-21 23:07:40 +02:00
|
|
|
prefix = _find_prefix (prefix_name);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
term = g_strdup_printf ("%s%s", prefix, value);
|
|
|
|
|
2009-10-21 23:10:00 +02:00
|
|
|
if (strlen (term) <= NOTMUCH_TERM_MAX)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
doc.add_term (term);
|
|
|
|
|
|
|
|
g_free (term);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
find_messages_by_term (Xapian::Database *db,
|
|
|
|
const char *prefix_name,
|
|
|
|
const char *value,
|
|
|
|
Xapian::PostingIterator *begin,
|
|
|
|
Xapian::PostingIterator *end)
|
|
|
|
{
|
|
|
|
Xapian::PostingIterator i;
|
|
|
|
char *term;
|
|
|
|
|
2009-10-21 23:07:40 +02:00
|
|
|
term = g_strdup_printf ("%s%s", _find_prefix (prefix_name), value);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
*begin = db->postlist_begin (term);
|
|
|
|
|
|
|
|
if (end)
|
|
|
|
*end = db->postlist_end (term);
|
|
|
|
|
|
|
|
free (term);
|
|
|
|
}
|
|
|
|
|
|
|
|
Xapian::Document
|
|
|
|
find_message_by_docid (Xapian::Database *db, Xapian::docid docid)
|
|
|
|
{
|
|
|
|
return db->get_document (docid);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
insert_thread_id (GHashTable *thread_ids, Xapian::Document doc)
|
|
|
|
{
|
|
|
|
string value_string;
|
|
|
|
const char *value, *id, *comma;
|
|
|
|
|
|
|
|
value_string = doc.get_value (NOTMUCH_VALUE_THREAD);
|
|
|
|
value = value_string.c_str();
|
|
|
|
if (strlen (value)) {
|
|
|
|
id = value;
|
|
|
|
while (*id) {
|
|
|
|
comma = strchr (id, ',');
|
|
|
|
if (comma == NULL)
|
|
|
|
comma = id + strlen (id);
|
|
|
|
g_hash_table_insert (thread_ids,
|
|
|
|
strndup (id, comma - id), NULL);
|
|
|
|
id = comma;
|
|
|
|
if (*id)
|
|
|
|
id++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-22 00:37:51 +02:00
|
|
|
notmuch_message_t *
|
|
|
|
notmuch_database_find_message (notmuch_database_t *notmuch,
|
|
|
|
const char *message_id)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
|
|
|
Xapian::PostingIterator i, end;
|
|
|
|
|
2009-10-22 00:37:51 +02:00
|
|
|
find_messages_by_term (notmuch->xapian_db,
|
|
|
|
"msgid", message_id, &i, &end);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-22 00:37:51 +02:00
|
|
|
if (i == end)
|
|
|
|
return NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-22 00:37:51 +02:00
|
|
|
return _notmuch_message_create (notmuch, notmuch, *i);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return one or more thread_ids, (as a GPtrArray of strings), for the
|
|
|
|
* given message based on looking into the database for any messages
|
|
|
|
* referenced in parents, and also for any messages in the database
|
|
|
|
* referencing message_id.
|
|
|
|
*
|
|
|
|
* Caller should free all strings in the array and the array itself,
|
|
|
|
* (g_ptr_array_free) when done. */
|
|
|
|
static GPtrArray *
|
2009-10-22 00:37:51 +02:00
|
|
|
find_thread_ids (notmuch_database_t *notmuch,
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
GPtrArray *parents,
|
|
|
|
const char *message_id)
|
|
|
|
{
|
2009-10-22 00:37:51 +02:00
|
|
|
Xapian::WritableDatabase *db = notmuch->xapian_db;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
Xapian::PostingIterator child, children_end;
|
|
|
|
Xapian::Document doc;
|
|
|
|
GHashTable *thread_ids;
|
|
|
|
GList *keys, *l;
|
|
|
|
unsigned int i;
|
|
|
|
const char *parent_message_id;
|
|
|
|
GPtrArray *result;
|
|
|
|
|
|
|
|
thread_ids = g_hash_table_new_full (g_str_hash, g_str_equal,
|
|
|
|
free, NULL);
|
|
|
|
|
|
|
|
find_messages_by_term (db, "ref", message_id, &child, &children_end);
|
|
|
|
for ( ; child != children_end; child++) {
|
|
|
|
doc = find_message_by_docid (db, *child);
|
|
|
|
insert_thread_id (thread_ids, doc);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < parents->len; i++) {
|
2009-10-22 00:37:51 +02:00
|
|
|
notmuch_message_t *parent;
|
|
|
|
notmuch_thread_ids_t *ids;
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
parent_message_id = (char *) g_ptr_array_index (parents, i);
|
2009-10-22 00:37:51 +02:00
|
|
|
parent = notmuch_database_find_message (notmuch, parent_message_id);
|
|
|
|
if (parent == NULL)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (ids = notmuch_message_get_thread_ids (parent);
|
|
|
|
notmuch_thread_ids_has_more (ids);
|
|
|
|
notmuch_thread_ids_advance (ids))
|
|
|
|
{
|
|
|
|
const char *id;
|
|
|
|
|
|
|
|
id = notmuch_thread_ids_get (ids);
|
|
|
|
g_hash_table_insert (thread_ids, strdup (id), NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_message_destroy (parent);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
result = g_ptr_array_new ();
|
|
|
|
|
|
|
|
keys = g_hash_table_get_keys (thread_ids);
|
|
|
|
for (l = keys; l; l = l->next) {
|
|
|
|
char *id = (char *) l->data;
|
|
|
|
g_ptr_array_add (result, id);
|
|
|
|
}
|
|
|
|
g_list_free (keys);
|
|
|
|
|
|
|
|
/* We're done with the hash table, but we've taken the pointers to
|
|
|
|
* the allocated strings and put them into our result array, so
|
|
|
|
* tell the hash not to free them on its way out. */
|
|
|
|
g_hash_table_steal_all (thread_ids);
|
|
|
|
g_hash_table_unref (thread_ids);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
/* Advance 'str' past any whitespace or RFC 822 comments. A comment is
|
|
|
|
* a (potentially nested) parenthesized sequence with '\' used to
|
|
|
|
* escape any character (including parentheses).
|
|
|
|
*
|
|
|
|
* If the sequence to be skipped continues to the end of the string,
|
|
|
|
* then 'str' will be left pointing at the final terminating '\0'
|
|
|
|
* character.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
skip_space_and_comments (const char **str)
|
|
|
|
{
|
|
|
|
const char *s;
|
|
|
|
|
|
|
|
s = *str;
|
|
|
|
while (*s && (isspace (*s) || *s == '(')) {
|
|
|
|
while (*s && isspace (*s))
|
|
|
|
s++;
|
|
|
|
if (*s == '(') {
|
|
|
|
int nesting = 1;
|
|
|
|
s++;
|
|
|
|
while (*s && nesting) {
|
|
|
|
if (*s == '(')
|
|
|
|
nesting++;
|
|
|
|
else if (*s == ')')
|
|
|
|
nesting--;
|
|
|
|
else if (*s == '\\')
|
|
|
|
if (*(s+1))
|
|
|
|
s++;
|
|
|
|
s++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*str = s;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse an RFC 822 message-id, discarding whitespace, any RFC 822
|
|
|
|
* comments, and the '<' and '>' delimeters.
|
|
|
|
*
|
|
|
|
* If not NULL, then *next will be made to point to the first character
|
|
|
|
* not parsed, (possibly pointing to the final '\0' terminator.
|
|
|
|
*
|
|
|
|
* Returns a newly allocated string which the caller should free()
|
|
|
|
* when done with it.
|
|
|
|
*
|
|
|
|
* Returns NULL if there is any error parsing the message-id. */
|
|
|
|
static char *
|
|
|
|
parse_message_id (const char *message_id, const char **next)
|
|
|
|
{
|
|
|
|
const char *s, *end;
|
2009-10-21 19:07:34 +02:00
|
|
|
char *result;
|
2009-10-19 21:54:40 +02:00
|
|
|
|
|
|
|
if (message_id == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
s = message_id;
|
|
|
|
|
|
|
|
skip_space_and_comments (&s);
|
|
|
|
|
|
|
|
/* Skip any unstructured text as well. */
|
|
|
|
while (*s && *s != '<')
|
|
|
|
s++;
|
|
|
|
|
|
|
|
if (*s == '<') {
|
|
|
|
s++;
|
|
|
|
} else {
|
|
|
|
if (next)
|
|
|
|
*next = s;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_space_and_comments (&s);
|
|
|
|
|
|
|
|
end = s;
|
|
|
|
while (*end && *end != '>')
|
|
|
|
end++;
|
|
|
|
if (next) {
|
|
|
|
if (*end)
|
|
|
|
*next = end + 1;
|
|
|
|
else
|
|
|
|
*next = end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (end > s && *end == '>')
|
|
|
|
end--;
|
2009-10-21 19:07:34 +02:00
|
|
|
if (end <= s)
|
2009-10-19 21:54:40 +02:00
|
|
|
return NULL;
|
2009-10-21 19:07:34 +02:00
|
|
|
|
|
|
|
result = strndup (s, end - s + 1);
|
|
|
|
|
|
|
|
/* Finally, collapse any whitespace that is within the message-id
|
|
|
|
* itself. */
|
|
|
|
{
|
|
|
|
char *r;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
for (r = result, len = strlen (r); *r; r++, len--)
|
|
|
|
if (*r == ' ' || *r == '\t')
|
|
|
|
memmove (r, r+1, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
2009-10-19 21:54:40 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse a References header value, putting a copy of each referenced
|
|
|
|
* message-id into 'array'. */
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
static void
|
|
|
|
parse_references (GPtrArray *array,
|
2009-10-19 21:54:40 +02:00
|
|
|
const char *refs)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-19 21:54:40 +02:00
|
|
|
char *ref;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
if (refs == NULL)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
return;
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
while (*refs) {
|
|
|
|
ref = parse_message_id (refs, &refs);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
if (ref)
|
|
|
|
g_ptr_array_add (array, ref);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
char *
|
|
|
|
notmuch_database_default_path (void)
|
|
|
|
{
|
|
|
|
if (getenv ("NOTMUCH_BASE"))
|
|
|
|
return strdup (getenv ("NOTMUCH_BASE"));
|
|
|
|
|
|
|
|
return g_strdup_printf ("%s/mail", getenv ("HOME"));
|
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
notmuch_database_t *
|
|
|
|
notmuch_database_create (const char *path)
|
|
|
|
{
|
2009-10-20 18:56:25 +02:00
|
|
|
notmuch_database_t *notmuch = NULL;
|
|
|
|
char *notmuch_path = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
struct stat st;
|
|
|
|
int err;
|
2009-10-20 18:56:25 +02:00
|
|
|
char *local_path = NULL;
|
|
|
|
|
|
|
|
if (path == NULL)
|
|
|
|
path = local_path = notmuch_database_default_path ();
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
err = stat (path, &st);
|
|
|
|
if (err) {
|
|
|
|
fprintf (stderr, "Error: Cannot create database at %s: %s.\n",
|
|
|
|
path, strerror (errno));
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (! S_ISDIR (st.st_mode)) {
|
|
|
|
fprintf (stderr, "Error: Cannot create database at %s: Not a directory.\n",
|
|
|
|
path);
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_path = g_strdup_printf ("%s/%s", path, ".notmuch");
|
|
|
|
|
|
|
|
err = mkdir (notmuch_path, 0755);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
fprintf (stderr, "Error: Cannot create directory %s: %s.\n",
|
|
|
|
notmuch_path, strerror (errno));
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
notmuch = notmuch_database_open (path);
|
|
|
|
|
|
|
|
DONE:
|
|
|
|
if (notmuch_path)
|
|
|
|
free (notmuch_path);
|
|
|
|
if (local_path)
|
|
|
|
free (local_path);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
return notmuch;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_database_t *
|
|
|
|
notmuch_database_open (const char *path)
|
|
|
|
{
|
2009-10-20 18:56:25 +02:00
|
|
|
notmuch_database_t *notmuch = NULL;
|
|
|
|
char *notmuch_path = NULL, *xapian_path = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
struct stat st;
|
|
|
|
int err;
|
2009-10-20 18:56:25 +02:00
|
|
|
char *local_path = NULL;
|
|
|
|
|
|
|
|
if (path == NULL)
|
|
|
|
path = local_path = notmuch_database_default_path ();
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
notmuch_path = g_strdup_printf ("%s/%s", path, ".notmuch");
|
|
|
|
|
|
|
|
err = stat (notmuch_path, &st);
|
|
|
|
if (err) {
|
2009-10-20 19:14:00 +02:00
|
|
|
fprintf (stderr, "Error opening database at %s: %s\n",
|
|
|
|
notmuch_path, strerror (errno));
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
xapian_path = g_strdup_printf ("%s/%s", notmuch_path, "xapian");
|
|
|
|
|
2009-10-21 23:00:37 +02:00
|
|
|
notmuch = talloc (NULL, notmuch_database_t);
|
|
|
|
notmuch->path = talloc_strdup (notmuch, path);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
try {
|
|
|
|
notmuch->xapian_db = new Xapian::WritableDatabase (xapian_path,
|
|
|
|
Xapian::DB_CREATE_OR_OPEN);
|
2009-10-21 09:35:56 +02:00
|
|
|
notmuch->query_parser = new Xapian::QueryParser;
|
|
|
|
notmuch->query_parser->set_default_op (Xapian::Query::OP_AND);
|
|
|
|
notmuch->query_parser->set_database (*notmuch->xapian_db);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
fprintf (stderr, "A Xapian exception occurred: %s\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
}
|
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
DONE:
|
|
|
|
if (local_path)
|
|
|
|
free (local_path);
|
|
|
|
if (notmuch_path)
|
|
|
|
free (notmuch_path);
|
|
|
|
if (xapian_path)
|
|
|
|
free (xapian_path);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
return notmuch;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
notmuch_database_close (notmuch_database_t *notmuch)
|
|
|
|
{
|
2009-10-21 09:35:56 +02:00
|
|
|
delete notmuch->query_parser;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
delete notmuch->xapian_db;
|
2009-10-21 23:00:37 +02:00
|
|
|
talloc_free (notmuch);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
notmuch_database_get_path (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
return notmuch->path;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_add_message (notmuch_database_t *notmuch,
|
|
|
|
const char *filename)
|
|
|
|
{
|
|
|
|
Xapian::WritableDatabase *db = notmuch->xapian_db;
|
|
|
|
Xapian::Document doc;
|
2009-10-21 00:09:51 +02:00
|
|
|
notmuch_message_file_t *message;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
GPtrArray *parents, *thread_ids;
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
const char *refs, *in_reply_to, *date, *header;
|
2009-10-20 08:08:49 +02:00
|
|
|
const char *from, *to, *subject;
|
2009-10-19 21:54:40 +02:00
|
|
|
char *message_id;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
time_t time_value;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
unsigned int i;
|
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
message = notmuch_message_file_open (filename);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
notmuch_message_file_restrict_headers (message,
|
|
|
|
"date",
|
|
|
|
"from",
|
|
|
|
"in-reply-to",
|
|
|
|
"message-id",
|
|
|
|
"references",
|
|
|
|
"subject",
|
|
|
|
(char *) NULL);
|
2009-10-19 22:48:13 +02:00
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
try {
|
|
|
|
doc.set_data (filename);
|
|
|
|
|
2009-10-21 09:34:36 +02:00
|
|
|
add_term (doc, "type", "mail");
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
parents = g_ptr_array_new ();
|
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
refs = notmuch_message_file_get_header (message, "references");
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
parse_references (parents, refs);
|
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
in_reply_to = notmuch_message_file_get_header (message, "in-reply-to");
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
parse_references (parents, in_reply_to);
|
2009-10-19 21:54:40 +02:00
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
for (i = 0; i < parents->len; i++)
|
|
|
|
add_term (doc, "ref", (char *) g_ptr_array_index (parents, i));
|
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
header = notmuch_message_file_get_header (message, "message-id");
|
2009-10-19 21:54:40 +02:00
|
|
|
if (header) {
|
|
|
|
message_id = parse_message_id (header, NULL);
|
|
|
|
/* So the header value isn't RFC-compliant, but it's
|
|
|
|
* better than no message-id at all. */
|
|
|
|
if (message_id == NULL)
|
|
|
|
message_id = xstrdup (header);
|
|
|
|
} else {
|
|
|
|
/* XXX: Should generate a message_id here, (such as a SHA1
|
|
|
|
* sum of the message itself) */
|
|
|
|
message_id = NULL;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-22 00:37:51 +02:00
|
|
|
thread_ids = find_thread_ids (notmuch, parents, message_id);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
for (i = 0; i < parents->len; i++)
|
|
|
|
g_free (g_ptr_array_index (parents, i));
|
|
|
|
g_ptr_array_free (parents, TRUE);
|
|
|
|
if (message_id) {
|
|
|
|
add_term (doc, "msgid", message_id);
|
|
|
|
doc.add_value (NOTMUCH_VALUE_MESSAGE_ID, message_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (thread_ids->len) {
|
|
|
|
unsigned int i;
|
|
|
|
GString *thread_id;
|
|
|
|
char *id;
|
|
|
|
|
|
|
|
for (i = 0; i < thread_ids->len; i++) {
|
|
|
|
id = (char *) thread_ids->pdata[i];
|
|
|
|
add_term (doc, "thread", id);
|
|
|
|
if (i == 0)
|
|
|
|
thread_id = g_string_new (id);
|
|
|
|
else
|
|
|
|
g_string_append_printf (thread_id, ",%s", id);
|
|
|
|
|
|
|
|
free (id);
|
|
|
|
}
|
|
|
|
doc.add_value (NOTMUCH_VALUE_THREAD, thread_id->str);
|
|
|
|
g_string_free (thread_id, TRUE);
|
|
|
|
} else if (message_id) {
|
|
|
|
/* If not part of any existing thread, generate a new thread_id. */
|
|
|
|
thread_id_t thread_id;
|
|
|
|
|
|
|
|
thread_id_generate (&thread_id);
|
|
|
|
add_term (doc, "thread", thread_id.str);
|
|
|
|
doc.add_value (NOTMUCH_VALUE_THREAD, thread_id.str);
|
|
|
|
}
|
|
|
|
|
2009-10-20 22:05:45 +02:00
|
|
|
g_ptr_array_free (thread_ids, TRUE);
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
free (message_id);
|
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
date = notmuch_message_file_get_header (message, "date");
|
2009-10-19 21:54:40 +02:00
|
|
|
time_value = notmuch_parse_date (date, NULL);
|
|
|
|
|
|
|
|
doc.add_value (NOTMUCH_VALUE_DATE,
|
|
|
|
Xapian::sortable_serialise (time_value));
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
from = notmuch_message_file_get_header (message, "from");
|
|
|
|
subject = notmuch_message_file_get_header (message, "subject");
|
|
|
|
to = notmuch_message_file_get_header (message, "to");
|
2009-10-20 08:08:49 +02:00
|
|
|
|
|
|
|
if (from == NULL &&
|
|
|
|
subject == NULL &&
|
|
|
|
to == NULL)
|
|
|
|
{
|
2009-10-21 00:09:51 +02:00
|
|
|
notmuch_message_file_close (message);
|
2009-10-20 08:08:49 +02:00
|
|
|
return NOTMUCH_STATUS_FILE_NOT_EMAIL;
|
|
|
|
} else {
|
|
|
|
db->add_document (doc);
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
fprintf (stderr, "A Xapian exception occurred: %s.\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
}
|
|
|
|
|
2009-10-21 00:09:51 +02:00
|
|
|
notmuch_message_file_close (message);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|