Skip to main content

Re: B2B/PendingMessage Discussion/ Meeting notes

  • From: Binod < >
  • To:
  • Subject: Re: B2B/PendingMessage Discussion/ Meeting notes
  • Date: Fri, 21 Jun 2013 10:56:01 +0530

Keith,

There are different kind of users for a standard Java specification. There are folks
who are familiar with different old versions of the standard and follow how the specification
is evolved etc. There are also a significant number of users who look at the standard
starting from the new revision we are producing.

My concern is not whether the basic SipServlets will work or not. Sure, the code can
cast the object to the right type. But the person who is looking at the interface would
find it strange, when they see a doInvite method accepting SipServletRequest, when there
is already a SipInviteRequest interface.

The pattern of the API should be understandable to the "new" developers. I don't think
we can expect them to figure out how the API was evolved over the years.

While for the specific problem you are looking at, the methods
does appear to fit in a method specific interface, unfortunately it make the basic constructs
of API non-intuitive.

thanks,
Binod.

On Friday 21 June 2013 01:19 AM, Lewis, Keith wrote:
" type="cite">
Binod,

No I am not suggesting that we deprecate the SipServlet class - this can still be used but it would be necessary to cast a SipServletRequest into the specific interfaces such as SipInviteRequest in order to access any methods on the new interface.

What I am suggesting is that we can reduce the need for casting in the case of Pojo servlets since we do not have to worry about backwards compatibility. We could allow processing methods to take a specific interface so we would have.

@Invite
public void handleInviteRequest(SipInviteRequest request) {
//...
}

in fact we could use the signature of the method to control when it was used and replace the @Invite annotation with a general @SipMessage annotation.

@SipMessage
public void handleInviteRequest(SipInviteRequest request) {
//...
}

We would remove the @SipMethod meta annotation, all the method specific annotations @Invite, @Register etc.
Instead the developer would use the method specific interface to indicate the type of message they would like to receive. We would also remove the @AnyMethod annotation and instead use a method that takes a SipServeletRequest (or SipServletResponse).

For responses we would keep the @ProvisionalResponse, @SuccessResponse annotations but these could be combined with a message specific interface such as SipRegisterRequest  to select only a success response to a register.

To my mind this seems a simple, natural style that developers would find easy to use and fits well with the Java language.

Keith


On Thu, Jun 20, 2013 at 10:27 AM, Binod < " target="_blank"> > wrote:
On Thursday 20 June 2013 06:37 AM, Lewis, Keith wrote:
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.


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





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

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