1
0
Fork
You've already forked notmuch-rs
0
Rust interface and bindings for notmuch (Downstream Fork) https://github.com/vhdirk/notmuch-rs
  • Rust 100%
Find a file
2018年11月12日 07:58:50 -05:00
src Switch to where syntax 2018年11月12日 07:58:50 -05:00
tests trust clippy and rustfmt 2018年11月07日 21:08:15 +01:00
.gitignore Add .gitignore file. 2015年03月13日 15:53:40 -04:00
.travis.yml prevent travis from building with features that are not available 2018年10月06日 12:14:55 +02:00
Cargo.toml bump version 2018年11月07日 21:09:22 +01:00
LICENSE.md add license 2018年04月14日 11:48:34 +02:00
README.md Simplify example in README 2018年11月12日 07:58:34 -05:00

notmuch-rs

This is not much more than a wrapper for the notmuch C api.

Build Status Crate version Download statistics License

Building

notmuch-rs expects libnotmuch development files to be installed on your system.

Using

Add this to your Cargo.toml:

[dependencies]
notmuch = "*"

and this to your crate root:

externcratenotmuch;

Example

externcratenotmuch;usenotmuch::StreamingIterator;fn main(){letmutmail_path=std::env::home_dir().unwrap();mail_path.push(".mail");letdb=notmuch::Database::open(&mail_path,notmuch::DatabaseMode::ReadOnly).unwrap();letquery=db.create_query("").unwrap();letmutthreads=query.search_threads().unwrap();whileletSome(thread)=threads.next(){println!("thread {:?}{:?}",thread.subject(),thread.authors());}}

Concurrency

Notmuch makes no claims regarding thread safety. It does not seem to use any thread locals, but I did not spot any locks. So, as far as I am concerned, it is not thread safe.
So why do all structs implement Send and Sync? Well, it is safe to access pointers from different threads (as long as you know what you are doing :) ). Up till now I haven't done a lot of multithreaded stuff with notmuch-rs. If you feel this is too permissive, let me know.

Lifetime

All structs are strictly linked together with their lifetime. The root of the tree is Database, which has a lifetime that must outlive any child objects, for instance Query. The Threads iterator that you can get from a Query is always outlived by the parent query. Threads in its turn must have a longer life than Thread, which in turn must outlive Messages and so on. Each structure keeps a PhantomData marker of its owner.

Using this in an application poses significant difficulties in satisfying these lifetime requirements. To alleviate this, notmuch-rs makes use of the excellent Supercow, so you don't have to use crates like owningref or rental to get around this.

This way, you get to choose your own container type, and even keep the parent object alive so you don't have to juggle lifetimes. To use this, most types are accompagnied with an *Ext trait, that accepts Rc, Arc or comparable.

usestd::sync::Arc;usenotmuch::{DatabaseExt};letquery={letdbr=Arc::new(db);<DatabaseasDatabaseExt>::create_query(dbr.clone(),&"".to_string()).unwrap()};

Iterators

Since the lifetime of a Thread or a Message is dependent on the Threads and Messages iterator respectively, using the regular rust Iterator trait proved impossible. As such, notmuch-rs includes a StreamingIterator (and additional StreamingIteratorExt) trait that is used to iterate while satisfying the lifetime constraints.

Acknowledgements

notmuch-rs started out from the following projects:

Any contributions are welcome!