Re: [Nmh-workers] mime-aware filtering?

[Ken Hornstein]

>at a high level, how do people feel about callbacks vs. state blobs?
>that is, would we like the replacement for m_getfld() to continue to
>return each time it finds something, maintaining its state in a
>caller-supplied opaque state blob, or would we like it to call the
>caller's "work function" every time it discovers a new object?
>that's the level we have to plan at, if we're going to get MH out of the
>1980's. (where it totally ruled, btw.)

So I've been inside all of that code a lot more than when we first had
that discussion in January.

In my experience, callers of m_getfld() want one of two things:

- They want everthing of a particular "thing".  They want all headers (to
  iterate over all of them) or the complete body (to search/display it).
  Example: show.
- They want ONE particular thing; they just have to look through the whole
  parts to do it.  Example: anything that uses mh-format; right now the
  current design of m_getfld() means you have to look over all of headers
  to get the ones you care about.  It would make things a lot cleaner if
  the API just let us pick out the one(s) we care about.

As for callbacks versus state blobs, I think callbacks are fine for
threaded or event-driven programming where you tend to do things
asychronously.  But since we're going to be pretty synchronous (I
think) I'd rather have state blobs.

--Ken