Re: [reSIProcate] proposed accessors for SipMessage raw body
Hi,
Thanks for sharing more details :)
While trying to exercise your patch I realized the intricacies between SipMessage::mContents and SipMessage::mContentsHfv (i.e. sometimes both are not used, most likely to save memory when copying messages, parsing cycles, ...).
Now that I'm aware of those I think your patch is a really good idea (i.e. more flexible API), as long as the end users know what they're doing ;).
Cheers,
Francis
On Thu, Mar 17, 2011 at 12:11 PM, Kennard White
<kennard_white@xxxxxxxxxxxx> wrote:
Hi Francis,
I agree that the Contents class mechanism is nice, and I think it very well handles the majority of use cases. (That is, once one figures it out).
I think resip will already defaults to an OctetContents if the content type is unknown (though there is a noisy log message).
In my immediate case, it is just an issue of code layering: I have a parser that is implemented "above" resip (not aware of resip classes), and integrating it into the ContentBase and Factory world is just more work than I want to do: coding-wise, it is easier just to extract the raw body and parse it. Performance-wise, even using an octet stream, there is an extra allocating and copying going on.
Aside from layering, laziness and performance, I suspect the main reason for not using the Content mechanisms is state-dependent parsing. That is, parsing it differently depending upon "other" information. For example, the content might be parsed into user-specific memory chunk. Or the desired representation (the particular Contents-like class) might depend upon app-level state for how it wants to use the body.
Regards,
KennardOn Thu, Mar 17, 2011 at 5:22 AM, Francis Joanis
<francis.joanis@xxxxxxxxx> wrote:
Hi Kennard,
What exactly is your use case? Handling a lot of 'unknown' content types?
I think it is a good idea to have a similar API to *RawHeader but I also like the ability to have customized objects to represent body types (you can dynamic_cast them, store custom data in them, have type safety, ...).
If your need is to handle unknown types, I wonder if using (or refactoring) GenericContents or PlainContents (or maybe creating an actual RawContents class) would work.
Regards,
Francis