Re: [PATCH 0/6] API for iterating over all messages in a thread

[Mark Walters <markwalters1009@gmail.com>]

Hi

This series looks good to me (I have not reviewed the two bindings
patches). Patch 2 looks like it makes things much easier to follow than
the current code (if I understood the current pointer stuff it
constructs the top-level list by doing pointer stuff to remove all
messages which are replies from the complete message list). Indeed, the
diff is more complicated than the new code!

On Sun, 25 Nov 2012, Austin Clements <amdragon@MIT.EDU> wrote:
> This series adds a library API for iterating over all messages in a
> thread in sorted order.  This is easy for the library to provide and
> difficult to obtain from the current API.  Plus, if you don't count
> the code added to the bindings, this series is actually a net
> decrease of 4 lines of code because of simplifications it enables.
>
> Do we want the API to do more?  Currently it's very minimal, but I can
> imagine two ways it could be generalized.  It could take an argument
> to indicate which message list to return, which could be all messages,
> matched messages, top-level messages, or maybe even unmatched messages
> (possibly all in terms of message flags).  It could also take an
> argument indicating the desired sort order.  Currently, the caller can
> use existing message flag APIs to distinguish matched and unmatched
> messages and there's a separate function for the top-level messages.
> However, if the API could do all of these things, it would subsume
> various other API functions, such as notmuch_thread_get_*_date.

I don't know if this is the right API. For the matched message etc I
think using the existing message flag APIs is simple enough. I am not
sure about sort orders though: that looks like it would be much easier
for the caller to have the correct sort by I am not sure what users
would need it.

Best wishes

Mark




>
> Also, is this the right name for the new API?  In particular, if we do
> later want to add a function that returns, say, the list of matched
> messages, we'll have a convention collision with
> notmuch_thread_get_matched_messages, which returns only a count.