On Fri 2016-06-03 19:12:52 -0400, David Bremner wrote:
>>> [ dkg wrote: ]
* for messages which have multiple files, which file is actually indexed
>>>
>>> yes. Although rather than storing that, I think the right answer is more
>>> like "all of them".
>>
>> I don't think we do this, do we? I
Daniel Kahn Gillmor writes:
> [ Unknown signature status ]
> On Fri 2016-06-03 08:54:00 -0400, David Bremner wrote:
>> Sure, where do you think that kind of documentation is appropriate?
>> There is the giant comment about the database schema in
>> lib/database.cc. Actually I just noticed I alrea
On Fri 2016-06-03 08:54:00 -0400, David Bremner wrote:
> Sure, where do you think that kind of documentation is appropriate?
> There is the giant comment about the database schema in
> lib/database.cc. Actually I just noticed I already failed to update that
> for libconfig stuff.
That comment seem
Daniel Kahn Gillmor writes:
>
> I think this makes sense, and makes me more comfortable with the overall
> idea of this patch series. maybe it'd be useful to clearly document the
> intended scope?
>
Sure, where do you think that kind of documentation is appropriate?
There is the giant comment a
Hi Bremner--
thanks for the response! I didn't mean my post to be a wet-blanket,
just wanted to think through the tradeoffs...
On Wed 2016-06-01 19:29:59 -0400, David Bremner wrote:
> I guess if you don't care about the possibility of iterating all pairs
> with given key prefix (which I admit ma
Daniel Kahn Gillmor writes:
> On Tue 2016-05-31 21:52:06 -0400, Daniel Kahn Gillmor wrote:
>
> do we actually need this abstraction? If we're aiming to build specific
> new features (the two i'm thinking of are cryptographic-session-keys and
> reference-adjustments), couldn't we implement those
On Tue 2016-05-31 21:52:06 -0400, Daniel Kahn Gillmor wrote:
> Thanks for working on this, David! I think this is going to be really
> useful!
just thinking about this series this morning in a bigger-picture way, i
figure it's worth asking the hard questions now rather than later --
maybe the ans
Daniel Kahn Gillmor writes:
> The other concern is our conception of how properties are unset/removed,
> right?
>
> With tags, it's possible to include -blah to remove the tag "blah". how
> do we remove/clear/overwrite these tags? what about using +key=val or
> -key=val to set/unset certain key
On Wed, Jun 01 2016, Daniel Kahn Gillmor wrote:
> On Tue 2016-05-31 21:12:21 -0400, David Bremner wrote:
>> I was thinking a bit about how to dump/restore these.
>>
>> The most upwardly compatible way that i thought of is something like
>>
>> #= msg-id key=val key=val
>>
>> i.e. duplicate the ms
On Wed, Jun 01 2016, David Bremner wrote:
> David Bremner writes:
>
>> + notmuch_message_properties_t *list;
>> + RUN(notmuch_message_add_property (message, "testkey1", "bob"));
>> + RUN(notmuch_message_add_property (message, "testkey1", "testvalue2"));
>> + RUN(notmuch_message_add_prope
On Tue 2016-05-31 21:12:21 -0400, David Bremner wrote:
> I was thinking a bit about how to dump/restore these.
>
> The most upwardly compatible way that i thought of is something like
>
> #= msg-id key=val key=val
>
> i.e. duplicate the msg-id for messages with properties
>
> This would be ignored
David Bremner writes:
> + notmuch_message_properties_t *list;
> + RUN(notmuch_message_add_property (message, "testkey1", "bob"));
> + RUN(notmuch_message_add_property (message, "testkey1", "testvalue2"));
> + RUN(notmuch_message_add_property (message, "testkey1", "alice"));
> +
> + for
This is a thin wrapper around the string map iterator API just introduced.
---
lib/message-property.cc | 38 +++
lib/notmuch.h | 24
test/T610-message-property.sh | 87 +++
3 files changed, 149 insertions(+)
13 matches
Mail list logo
