1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
# notmuch-rs
This is not much more than a wrapper for the [notmuch](https://notmuchmail.org/) C api.
[](https://travis-ci.org/vhdirk/notmuch-rs)
[](https://crates.io/crates/notmuch)
[](https://crates.io/crates/notmuch)
[](https://crates.io/crates/notmuch)
## Building
**notmuch-rs** expects libnotmuch development files to be installed on your system.
## Using
Add this to your `Cargo.toml`:
```toml
[dependencies]
notmuch = "*"
```
and this to your crate root:
```rust
extern crate notmuch;
```
## Example
```rust
extern crate notmuch;
use notmuch::StreamingIterator;
fn main() {
let mut mail_path = std::env::home_dir().unwrap();
mail_path.push(".mail");
let db = notmuch::Database::open(&mail_path, notmuch::DatabaseMode::ReadOnly).unwrap();
let query = db.create_query("").unwrap();
let mut threads = query.search_threads().unwrap();
while let Some(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](https://crates.io/crates/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.
```rust
use std::sync::Arc;
use notmuch::{DatabaseExt};
let query = {
let dbr = Arc::new(db);
<Database as DatabaseExt>::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:
- https://github.com/Stebalien/notmuch-sys/blob/master/src/lib.rs
- https://github.com/cmhamill/rust-notmuch
Any contributions are welcome!
|
