[reSIProcate] proposed accessors for SipMessage raw body
Kennard White
kennard_white at logitech.com
Thu Mar 17 11:11:09 CDT 2011
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/c860e230/attachment.htm>
More information about the resiprocate-devel
mailing list