On Fri, Sep 27, 2013 at 10:08 PM, James Cloos <cloos+pjsip at jhcloos.com>wrote: > [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? > > Hi Jim, Not sure, actually. What kind of api break are we talking about here? If we are talking about binary compatibility (i.e. DLL), then doesn't adding a new field in a structure break compatibility anyway (e.g. different struct size)? FWIW, we don't normally maintain binary compatibility across releases, at least for now, only source compatibility. So unless there is other objections, I would prefer adding the new members in their "natural" places. I agree with adding "encoding", "encode()", and "decode()" to pjsip_msg_body. And I assume we'll have a new API for encoding and decoding as well. To clarify further, here are some sample scenarios. An incoming INVITE with gzipped body arrives. Parser parses the request, puts "gzip" to "encoding" member of the pjsip_msg_body, fills in "decode()" method, and set "encode" method to NULL. It does NOT decode the body to plain text at this stage (think about when we need to forward the request as a proxy). The invite session processes the INVITE request. It checks the "encoding" field of pjsip_msg_body, it sees "gzip", it calls decode(), and possibly overwrites the message body with the decoded plaintext and clears the "encoding" field (or maybe the global decoding API operates on msg body, hence these can be done automatically). Processing then resumes as usual. For outgoing messages, the stack will copy the "encoding" field to Content-Encoding header, and calls "encode()" method to the body if the "encoding" field is not empty and "encode()" method is not NULL. Thus to send already encoded body, app sets the "encoding" field but leaves out the "encode()" method to NULL, while to request the stack to encode the currently plain text body, app sets both "encoding" and "encode()" method to the appropriate values. Cheers Benny > Thank you. > > -JimC > -- > James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20130930/df3b4022/attachment-0001.html>
