On Wed, 29 Feb 2012 10:50:46 -0500, Jesse Rosenthal <jrosenthal@jhu.edu> wrote: > On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements <amdragon@MIT.EDU> wrote: > > What if the output of search (say, specifically the JSON format) > > included information on each message in the thread such as the > > 'message' production from devel/schemata minus the body field? Then > > the frontend would have loads of information it could produce its own > > summaries from. (Plus, with a little tweaking, I don't think this > > would be any more expensive than producing the current notmuch search > > summary output.) > > I was hoping for something like that when I started fiddling. But it's > still going to end up being a library question, because > notmuch-search.c, is tied pretty tightly to the lib: i.e. it uses > functions like `notmuch_thread_get_authors (thread)'. I was using the > python bindings, and I ended up having to make a second query off the > thread id (I could have recursed through the messages too, I suppose). > > So I guess what I'm saying is that what you're suggesting sounds great, > but we'd still have to either (a) add new library functions > (`notmuch_thread_get_recipients', `notmuch_thread_abbrev_me'), (b) keep > them all in the client and make pazz and scripters recreate them, or (c) > play around in the sort of client-library space that it sounded like > Bremner was suggesting. I was suggesting just using notmuch_thread_get_toplevel_messages in search (essentially, mixing a bit of show into search). No library changes necessary. It may still be useful to have a collection of *utilities* that could be reused in bindings; basically, things that currently live in the CLI but could be broken out. These should live outside of libnotmuch proper. My concern would be what we put in such a library. Currently, the CLI's internal architecture is quite agile, but as soon as you put some of that in a library, you have a library interface to support.