Re: notmuch-lib questions and observations

[Tomi Valkeinen <tomi.valkeinen@iki.fi>]

[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]

On 2013-11-19 14:12, Jani Nikula wrote:
> On Mon, 18 Nov 2013, Tomi Valkeinen <tomi.valkeinen@iki.fi> wrote:
>> Hi,
>>
>> I found out about notmuch quite recently, and now I've been tinkering
>> with it, prototyping a GUI client. I have some questions and observations:
> 
> Hello Tomi, glad you've found notmuch too! ;)

Well, I'm still using Thunderbird... ;)

>> 3.
>>
>> How is a client using notmuch supposed to find out there are new
>> messages, and which messages are new?
> 
> 'notmuch new' tags any new messages it finds with tags specified in
> new.tags config option (man notmuch-config), "inbox" and "unread" by
> default. Some people like to change that to "new", and run a post-new
> hook (man notmuch-hooks) that looks at messages matching tag:new,
> retagging as desired.
> 
>> My current thought is to make 'notmuch new' run a script that tags the
>> messages, and make it add a 'new-gui' or such tag to all new messages.
>> The client would then periodically make a query for that tag, and at the
>> same time remove the tag for any returned messages.
> 
> As said, 'notmuch new' does that, and it can also run a script for you.

I think I wasn't very clear on what I meant. I was thinking about the
behavior that graphical mail clients have: they periodically refresh the
emails, showing new ones if there are any, and they'll show some icon or
such which tells the user this email is "new" (which could mean received
in the last periodic refresh).

So with notmuch, the client would somehow need to know that there has
been changes in the database, and then know which emails are new.

For the former, I have no good idea as there doesn't seem to be any way
to find out the db was changed since the last open. For the latter, I
guess the tagging method I mentioned above should work.

If the xapian document id was available, I believe it could also be used
for the latter, as it should always be increasing.

>> 5.
>>
>> This one is just a vague thought that came to my mind. At the moment
>> notmuch hides Xapian totally behind notmuch's interface, which probably
>> makes things simpler (and gives a nice C API), but also (afaik) prevents
>> using Xapian features that are not at the moment supported in the
>> notmuch API.
>>
>> I wonder how would an approach work where notmuch would be a bit more
>> like a helper library, allowing full use of Xapian's features but making
>> it simple to manage notmuch database. So, for example, when making a
>> query, you'd create a Xapian query with notmuch, and then use Xapian to
>> run the query.
>>
>> I don't have anything clear in mind, and obviously Xapian being C++
>> might make the whole idea unimplementable.
> 
> I think the database implementation has been abstracted on purpose, so
> we could, at least in theory, switch from xapian to something else. I
> don't know how feasible that would be though. I think Austin has
> experimented with that.

Ah, a valid point, I didn't think of that.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]