[SIPSERVLET_SPEC-24] Improve header support by introducing a Header interface. Created: 02/Nov/12 Updated: 15/Jan/14 Resolved: 15/Jan/14
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
In 289, if you want to extract out all the headers out of a sip message you will end up writing a double for-loop to get all the headers and their values out. Also, you have to come up with your own structure for storing that information in a meaningful way. Consider the following example that extracts out all X-headers out of a message and returns them in a list:
Not shown in the above snippet is the Header class that holds the name and the value of the header.
Introduce a Header interface that all headers will inherit from (in the current specification that would be Parameterable only) and expose new convenience methods in SipServletMessage for extracting out all headers.
Note: full interface declaration at the end
With the new interface additions the same code for extracting out the x-headers:
This will also allow people to create their own Header library which would have a cleaner integration with the container because of the re-usable Header-interface.
|Comment by binod [ 29/Aug/13 ]|
Can we avoid "2" that is appearing in the method names? Since getHeader and getHeaders methods are already taken, one way to avoid the "2" might be by using "HeaderEntry" as the interface name instead of "Header".
Another question is, since SIP Servlet 1.1 has already defined Parameterable interface, how would Parameterable (and Address) values be handled? One way might be to define new interface as HeaderEntry<String, V> and then have the methods return HeaderEntry<String, String> or HeaderEntry<String, Parameterable>, when app invokes getHeaderEntry and getParameterableHeaderEntry respectively.
|Comment by jonbo372 [ 25/Sep/13 ]|
Agreed. As the javadoc says for the getHeader2, a better name is certainly needed. I don't really like getHeaderEntry (if I understood you correctly) because I don't like to change the name of the Header since it is a Header and not a HeaderEntry.
Parameterable and Address would simply inherit from the Header interface. Compare to JSR32. Hence, just cast it if you know it is of a certain type.
|Comment by binod [ 15/Jan/14 ]|
Given the way headers are specified as header values in the 1.1 API, it does not make much sense to introduce a headerfield that will disrupt the design in a non-intuitive way. So, EG decided not to pursue this API further. Please see the email thread below for details.