Re: Implemeting an ExtensionHeader

David,


I will answer on this thread one last time and then leave it at that.  
I'll try to be as objective as possible here.

[email protected] wrote:

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



The point behind JAIN is to try to make your application portable across 
different implementations of the standard. This includes Native code 
implementations of the stack, headers etc.  If we allowed for 
applications to be able to pass in their own implementations of  Header 
objects, this would not be possible. Hence, to simplify implementation 
headaches, and ensure portability, a conscious decision was made to not 
necessitate a requirement that a given provider be able to recognize 
Header implementations other than those created by  its own factory.  If 
this had not been one of the explicit design goals, we could have just 
supplied a set of header classes as part of the spec and done away with 
all the header interfaces and factories and whatnot.

The point is not that NIST implementation of JAIN-SIP does not allow 
what you are trying to do (although one could possibly get it to do that 
by just using the Interfaces throughout) but that it is not necessitated 
by the JAIN standard to allow vendor interoperability at that level. Now 
the JAIN spec COULD have been defined to allow for such interoperability 
but it does not. So thats it. It was a conscious design decision not to 
require it - not merely an implementation accident.


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



ExtensionHeader is essentially a marking interface. There is no 
ExtensionHeaderImpl supplied. The idea is that if somebody wants to 
support a new header Foo from a IETF draft and later the JSIP standard 
evolves to include Foo as a supported header, then the implementation 
for Foo SHOULD also implement ExtensionHeader for backwards 
compatibility. That way, older applications which are not aware of the 
JSIP FooHeader dont break.



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


You basically want to throw out the Factories and use new. Well, I dont 
think you will find much support for that requirement in the Java world. 

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


Jain sip has been around for a while and this is the first time anybody 
wanted to be able to supply their own Header implementation.

I think we are done with this thread (at least I am).

>
>> 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
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>


-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!