Skip to main content

Re: B2B/PendingMessage Discussion/ Meeting notes

  • From: Binod < >
  • To:
  • Subject: Re: B2B/PendingMessage Discussion/ Meeting notes
  • Date: Thu, 20 Jun 2013 14:57:39 +0530

On Thursday 20 June 2013 06:37 AM, Lewis, Keith wrote:
" type="cite">
Regarding sub-interfaces of SipServletRequest there would seem to be 3 options
A. Interfaces for a large set of SIP methods - some are empty marker interfaces
B No sub-interfaces
C Interfaces only where they are not empty e.g. SipAckRequest, SipPrackRequest, SipRegisterRequest etc

I agree with Eric and Jonas - A would be good.
If we do not get agreement for A then I think C is the next best option.

Given that we are defining the Pojo servlets in JSR359 we do have a clean slate in terms of whether pojo servlet methods can take message specific interfaces.
Are you proposing that we deprecate javax.servlet.sip.SipServlet ?

- Binod.

" type="cite">

The right thing to do for responses seems less clear, I had proposed to have sub-interfaces based on the class of the status code - SipProvisionalResponse, SipFinalResponse, SipSuccessResponse, SipRedirectResponse etc
Looking at the Javadocs I notice that there is a SipServletResponse.setStatus() method which makes this impossible. Having sub-interfaces based on the sip method seems less useful for responses.

Keith


On Tue, Jun 18, 2013 at 5:31 AM, Binod < " target="_blank"> > wrote:
On Tuesday 18 June 2013 12:38 AM, Eric Cheung wrote:
I have reviewed the proposals (i.e. 1(A), 1(B) and 2) and been following all the discussion on the mailing list in the last week and a half.  I realize that there are still open issues being discussed, but I vote for the general direction of 1(A).  I feel that it is more intuitive to have methods on the message classes, as opposed to a separate class that takes in a message as argument.

A few other points:

- To Binod's point about too many method specific interfaces without methods. (Or only some method specific interfaces), I think it is actually nice to define a hierarchy of interface classes for requests and responses for all SIP methods, even if most interfaces may not declare any methods.  This follows the marker interface pattern and should makes application code more type-safe.  Otherwise programmers need to do msg.getMethod().equals("INVITE") etc.
There are lot of arguments for and against using marker interface pattern as against providing a meta data. In our case, I don't think marker interfaces
suit the way the APIs are defined.

For example, in SipServlets, we have defined apis such as doInvite, doSubscribe etc... With a marker interface, I would define doRequest(SipInviteRequest) as against doInvite. However, our API defined a metadata in the form of getMethod() and went against marker interfaces.

So, should we also move from doInvite to doRequest? Can we do that without breaking existing applications?

I see the argument about the type safety. On a clean slate SIP Servlet specification, that argument would have been more acceptable.
However, given where we are, I feel these marker interfaces make the API more confusing than making it better.


- we need to be careful about the term 'pending'.  In JSR289 'pending' is used to mean 'un-committed', where 'committed' is defined in sec 5.2.  I believe in both proposals 1 and 2 the term pending means different things, i.e. the corresponding transaction is not terminated yet.

Agree. I think, Keith has started using the term "active". Whether we decide on (1) or (2), we can use "active messages".

thanks,
Binod.



Thanks
Eric




On Thursday 06 June 2013 04:02 PM, Binod wrote:
Attendees : Brian, Eric, George, Keith, Tom, Binod (Sorry, if I missed
anyone).

Keith's original proposal has now evolved to two different set of
proposals.

1. See Keith's e-mail with latest PDF. The approach in this proposal
is to
create a new interface called SipInviteRequest to hold pending responses
for invite. From yesterday's discussion, seems like there are two further
paths on this proposal.
(A) Define interfaces for methods also. For example,
SipRegisterRequest, SipAckRequest,
SipInviteResponse etc. This would make the API consistent across all
the methods.
(B) Move the new methods to SipServletRequest iteself.

2. The PendingMessages interface holds all the pending messages. See
the attached
changes to javadoc. I updated it with the comments from the discussion
yesterday.

Please let the EG know which path you would like to take for
standardizing this functionality. ?

thanks,
Binod.




 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3






Re: B2B/PendingMessage Discussion/ Meeting notes

(continued)

Re: B2B/PendingMessage Discussion/ Meeting notes

Jonas Borjesson 06/12/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

George Vagenas 06/12/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Eric Cheung 06/12/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Binod 06/13/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Binod 06/13/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Lewis, Keith 06/15/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Binod 06/14/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Eric Cheung 06/17/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Binod 06/18/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Lewis, Keith 06/20/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Binod 06/20/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Lewis, Keith 06/20/2013

Re: B2B/PendingMessage Discussion/ Meeting notes

Binod 06/21/2013
 
 
Close
loading
Please Confirm
Close