>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
