On Fri, 17 Nov 2006 at 21:12, M. Ranganathan wrote:
> 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.
Thanks for taking the time to answer. Your answer here cleared up a
bunch of stuff for me.
> [email protected] wrote:
> 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
This is where my non-java brain got confused. I didn't realize that
such data structures wouldn't be compatible.
> 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.
Yes, that was the source of my confusion, I see now.
> So thats it. It was a conscious design decision not to require it - not
> merely an implementation accident.
Got you. I guess that's what I was trying to understand: the design.
> 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.
Ah, _now_ I understand. When I saw that the spec said that it was
extensible, I thought that meant it was extensible by the application
programmer. Now I understand that it means extensible by the stack
implementor, and so now I understand what the ExtensionHeader interface
is for and how one would use it. Thanks!
> 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.
Different tools for different jobs. This one does the job it was
designed to do, as you have explained. Now that I understand that
job, it will be easier for me to work with the code.
I am working on modifying the source to be able to run the tests I need to
run, and will report back the results vis a vi Asterix interoperability.
And if this does turn out to "fix" the Asterix problem, be sure that I
will talk to them about the interoperability/standards compliance issues
this raises.
--David
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.