[I sent this yesterday from the wrong address; resending. -JimC] I'm working on adding support for Content-Encoding:deflate to pjsip. For the parser, handling inflation transparently seems necessary given the inline parsing of multipart bodies. That, then, is relatively easy. For generating a sip message, OTOH, I've looked at a number of paths and all -- other than forcing the application to provide a deflated body -- require an api break. So I'm looking for some idea of what is preferred. One possibility is to key on the existance of a Content-Encoding header; if that is found and has the value "deflate" then the code which generates the Content-Type and -Length headers can deflate() the body, too. But on its own that doesn't permit the app to provide an already deflated body. Or I could add an encoding member to the pjsip_msg_body struct; if that is set to ..._DEFLATE it can deflate the body and add the e: header with the c: and l: headers. With that, I could add encode() and decode() methods. Since that is a public struct, adding before the current function pointers breaks the api. Adding it after may look less clean. I think the latter is the better API, but unless the new member and methods are added at the end of the struct, everything compiled against the library will need re-compilation. As opposed only to those apps which want to take advantage of the progression. What is Teluu's preference on api stability for the addition? Thank you. -JimC -- James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
