On Fri, Nov 25, 2011, Wietse Venema wrote: [sorry for the late reply, I was hoping to get more answers from the people I contacted.]
> I'm sure libmilter API users will appreciate that the API for PDPR > replies is consistent with that of smfi_setreply / smfi_setmlreply. It seems I chose a bad name for the function, so let's call it smfi_prdr() to avoid this kind of confusion. The APIs of smfi_setreply() and smfi_setmlreply() versus smfi_prdr() are very different: - smfi_set*reply() are complementary functions that set a text reply for a return value. - There is no function that sets the return value for PRDR, smfi_prdr() does that. If I wanted to "mimic" smfi_set*reply() then I would have smfi_prdr() (well, actually xxfi_eom() but I can't change that API) setting return codes and an additional smfi_setreplies() setting corresponding return texts. I want to avoid this (I consider this a design failure, but we can't change that easily -- however, we don't need to repeat it). The formats of the text replies for smfi_set*reply() and smfi_prdr() are very different. For smfi_setmlreply() the library "assembles" the actual reply string based on the components, smfi_prdr() requires the user the provide the full text -- that makes the library simpler and it also makes the API simpler. I contacted some people who worked on milters etc but got only one reply which agreed with the suggested API, i.e., provide the array of reply codes and make the text optional (smfi_set*reply() is seemingly not used very often). > I care primarily that the on-the-wire format is consistent with > SMFIR_REPLY, which transits one reply (including code, enhanced I understand that's an additional complexity, but this seems to be minor. > status, text) as one string whether the reply is multiline or not, > and with the same special handling of % characters. The handling of '%' seems to be bogus and I don't recall why we did that. It seems like a mistake (I might take a look at the cvs history when I have access to it again) -- I don't see how it is useful for anything. Unless there is a technical argument in its favour, I prefer to treat the strings as constant (not subject to any interpretation/modification). [I might say that I learned a lot from writing libmilter and developing the protocol; I tried to make it better twice: first in milter v2 which allows for option negotiation, and then a new version for MeTA1 without the need for backward compatibility. Hence the API for smfi_prdr() is different and IMHO better.]
