On Aug 16, 2014, at 7:35 PM, James Peach <jpe...@apache.org> wrote: > On Aug 16, 2014, at 8:29 AM, Brian Geffon <briangef...@gmail.com> wrote: > >> I'm definitely +1 for functor/iterator semantics, ideally it could be done >> in such a way as to preserve backwards compatability. > > My initial reaction is against a callback-based API because that's not > consistent with the existing API patterns. An iterator is probably more > appropriate.
How so? We showed one case where we already do so (looping over all librecords). Maybe we should just fix that instead such that it follows whatever semantics amc had in mind? I’m not too concerned about changing the functors return values here, and we could also come up with a new naming scheme for all such APIs (and deprecate the old one). If we go the route of making a new version of TSMimeHdrFieldNext() we should consider TSMimeHdrFieldGet() instead. It’s just better in all cases I can think of for looping through this. TSMimeHdrFieldNext() was designed to allow you to look at the header “following” one that you’ve already found, and has some additional expenses (double loop over the headers to start with). Also, when we do this, we should consider either fixing our current plugins usage of TSMimeHdrFieldNext() (or at least file bugs). There’s some pretty inefficient stuff in a couple of places. At a minimum, they should use TSMimeHdrFieldGet(), more likely use normal getters and TSMimeHdrFieldNextDup(). Ciao, — Leif
