[reSIProcate] proposed accessors for SipMessage raw body

[Francis Joanis]

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 at logitech.com>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,
> Kennard
>
>
> On Thu, Mar 17, 2011 at 5:22 AM, Francis Joanis <francis.joanis at gmail.com>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
>>
>>
>>
>>
>> On Wed, Mar 16, 2011 at 2:47 PM, Kennard White <
>> kennard_white at logitech.com> wrote:
>>
>>> Hey,
>>>
>>> I'm proposing the attached patch which provides a way to get a message's
>>> raw body data without converting it into a resip::Contents class. The intent
>>> is to mimic the get/setRawHeader() accessors.
>>>
>>> Any comments?
>>>
>>> Thanks,
>>> Kennard
>>>
>>>
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110317/93395203/attachment.htm>