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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers