Re: [reSIProcate] Accessing headers on a URI

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	Yeah, unless we are seeing lots and lots of use of embedded headers,  
it probably isn't worth it. But, if this changes, it is something we  
might want to look into.

Best regards,
Byron Campen

> 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
> > >

Attachment: smime.p7s
Description: S/MIME cryptographic signature