Re: Implemeting an ExtensionHeader

On Fri, 17 Nov 2006 at 16:39, M. Ranganathan wrote:
> [email protected] wrote:
>>  Um, OK.  So what you are saying is that Headers are only conformant to
>>  the interface specification if they are obtained from the HeaderFactory?
>
> No that is not what I (or anybody else) is saying. You can supply your own 
> implementation of ContactHeader but the stack may cast it to 
> gov.nist.javax.sip.Contact (and create a class cast if it is not sublcassed 
> from gov.nist.javax.sip.Contact) and besides, the HeaderFactory will create 
> objects of type gov.nist.javax.sip.Contact and hence your sublcass will be 
> ignored.

Hmm.  So I can implement a ContactHeader, but since the nist addHeader
method casts the Header object that I pass it to SIPHeader, I'd have to
subclass SIPHeader to do it, which makes me dependent on a particular
implementation, doesn't it?  So to my inexperienced eye there doesn't
appear to be any way for me to implement my own header classes that
would be implementation agnostic.  I mean, I'm still not seeing how one
implements an ExtensionHeader using just the Interface and not touching
the implementation (since addHeader does that cast).

>>  It doesn't actually say that anywhere in the spec that I could find.
>>  Perhaps it would be obvious to an experienced Java programmer.
>
> The only way to explicitly create headers is through the header factory. Upon 
> examination of the specification one might learn that there is no other way 
> to create headers than explictly though the header factory and implicitly via 
> the MessageFactory.Therefore it is unambiguous.

Like I said, to a Java programmer that might be unambiguous, but just
because the Interface provides no other method for creating headers
doesn't a priori prevent me from creating an object that conforms to
the Interface specification for "Header".  To my non-java mind, that is
a perfectly legitimate "way to explicitly create" a header.  :)

So, I'm learning.

> pervasive and difficult. Besides, there is hardly much of use case for such a 
> feature. In any case, I have neither the time nor inclination to attempt it 
> nor is it required to be supported by the spec.

Yeah, I agree that my use case isn't much of one :)  I wouldn't be
surprised if there were others, but clearly you shouldn't spend any
time on any such changes unless _real_ use cases turn up.

> The code is all there for you to do what you want with. Nothing stops you 
> from editing the java file and redistributing it with your product or 
> project. You are basically asking for a way to deal with a stack that is not 
> standards compliant ( Asterisk in this case). Please do edit the source code 
> that is provided to you for exactly that purpose and make it deviate as much 
> from RFC 3261 as you wish.

Yeah, I'll do that.  I hate maintaining patched versions of stuff,
but reality is what it is.

>>  I wonder if this stems from a
>>  kind of culture clash between the proprietary world and the open
>>  source world I'm more familiar with.
>
> Ah nothing quite so deep. There is no conspiracy here.

Heh, I wasn't thinking there was a conspiracy :)  Just a different
approach to writing code.  Probably has more to do with the
difference in culture between python and java than between proprietary
and open source, now that I think about it.  It was the talk of
"vendor stack" that had me thinking of proprietary as a variable...

--David