Re: [reSIProcate] Accessing headers on a URI
I agree. This doesn't seem like a good place to optimize.
On 2/16/07, Adam Roach <adam@xxxxxxxxxxx> wrote:
The problem is that it's not just headers. It's headers and a method and
a body. There is, admittedly, some transport-related cruft that's not
strictly necessary for this use, but I doubt that the refactoring effort
and consequent design complexity is warranted unless someone is scaling
things down for embedded use.
/a
david Butcher wrote:
> Should be reasonably straight forward to extract HeadersHolder as
> parent of SipMessage.
> It is not enirely pretty how this interacts with TransactionMessage,
> but the simplicity of single inheritance probably warrants the warts.
>
> Note that this refactoring will make it even more difficult to figure
> out how to get headers out of a SIP message, sigh.
>
> How frequent are embedded headers?
>
> david
>
> On 2/16/07, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
>
>> Oh yes, it would just be nice to be able to do this without all the
>> extraneous stuff in SipMessage (mDestination, mSource, mContents,
>> mReason, mEncoded, mCompartmentId, etc).
>>
>> Best regards,
>> Byron Campen
>>
>>
>>> Keep in mind that it is possible to embed multiple headers into a URI.
>>> The current api is probably the most efficient way to get the desired
>>> functionality.
>>>
>>> Jason
>>>
>>>
>>> On 2/16/07, Will McKinley <wmckinle@xxxxxxxxx> wrote:
>>>
>>>> Sure thing.
>>>>
>>>>
>>>> On 2/16/07 11:31 AM, "Robert Sparks" <rjsparks@xxxxxxxxxxx> wrote:
>>>>
>>>>
>>>>> Will -
>>>>>
>>>>> If you see a place to make clarifying nudges on the wiki to help
>>>>>
>>>> the
>>>>
>>>>> next person that runs into this, please add them.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> RjS
>>>>>
>>>>> On Feb 16, 2007, at 10:02 AM, Byron Campen wrote:
>>>>>
>>>>>
>>>>>> You'll use the usual SipMessage::header accessor. I know this is
>>>>>> really heavy for just holding onto a single header-field-value,
>>>>>>
>>>> but
>>>>
>>>>>> right now there is no way to conveniently extract the "I hold
>>>>>> header-field-values" functionality from SipMessage (as opposed to
>>>>>> the "I hold transport information" and "I hold a payload"
>>>>>> functionality).
>>>>>>
>>>>>> Best regards,
>>>>>> Byron Campen
>>>>>>
>>>>>>
>>>>>>> Sorry to be a pest, but then what accessor on the SipMessage do I
>>>>>>> use to get
>>>>>>> to the hname/hvalue. The header accessor doesn't seem
>>>>>>>
>>>> appropriate
>>>>
>>>>>>> so I'm
>>>>>>> just wondering.
>>>>>>>
>>>>>>> Thanks again.
>>>>>>>
>>>>>>>
>>>>>>> On 2/16/07 10:53 AM, "Byron Campen" <bcampen@xxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Yeah, that's how it works. Kinda heavy.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Byron Campen
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I just need some clarification on how resip handles headers
>>>>>>>>>
>>>> on a
>>>>
>>>>>>>>> Sip URI. I
>>>>>>>>> noticed that the documentation pointed to the embedded()
>>>>>>>>>
>>>> method on
>>>>
>>>>>>>>> the Uri
>>>>>>>>> class, but this returns a SipMessage. This seems to be
>>>>>>>>>
>>>> overkill
>>>>
>>>>>>>>> for a
>>>>>>>>> hname/hvalue pair. Is this really the way it works?
>>>>>>>>>
>>>>>>>>> Your help is much appreciated.
>>>>>>>>> -Will
>>>>>>>>> _______________________________________________
>>>>>>>>> resiprocate-devel mailing list
>>>>>>>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>>>>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> resiprocate-devel mailing list
>>>>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>>
>>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>