[news.eclipse.technology.ecomm] Re: What about SIP/SIMPLE?

["John F. Patterson" <john_patterson@xxxxxxxxxx>]

Scott:

Glad to hear that SIP/SIMPLE is not precluded.  I do think virtualizing 
over all these approaches is a challenge, but it's the way to go.

jfp

Scott Lewis wrote:

> Hi John,
>
> John F. Patterson wrote:
>
> > Do you envision the possibility of SIP/SIMPLE implementations of your 
> > platform?
>
>
> Absolutely.  The general approach is:  define a small (3ish) set of 
> plugins that expose generic apis...for identity/authentication, pt2pt 
> and multipoint messaging, and a component api.  Underneath each api, 
> provide implementations to support existing protocols...e.g. 
> SIP/SIMPLE, XMPP, JMS, etc.  To allow for client-side interoperability.

I am curious about your factoring of the problem into 
identity/authentication, pt2pt and multipoint messaging, and a component 
api.  I tend to think of factoring the problem into directory, 
conferencing, and awareness/presence services.  I think of the 
componentry model as intrinsic to the services, i.e., components are 
extension points to the services.  This makes me wonder whether we are 
using the term component in the same way.  I think of chat, whiteboard, 
voice, screen sharing, etc, as components that extend a general 
conference object.  Is that the way you think about components?

I'm also wondering where awareness/presence ends up in your formulation.

> You actually caught me working on an implementation of the messaging 
> API to support communication via XMPP (Jabber protocol).  I would very 
> much like to include SIMPLE/SIP in that initial set of supported 
> messaging implementations, so that plugin developers could use ecomm 
> to easily talk with SI* servers and client.
>
> > Do you know of any reasons why this would be precluded?  Or, is it 
> > too early to say one way or the other?
>
>
> No, it certainly wouldn't/won't be precluded.  I'm realizing part of 
> the trick of the design of such generic apis is to make them 
> sufficiently abstract to handle these various messaging protocols (and 
> their various ways of doing security, different features, etc.) while 
> still providing an API that is useful at the application level.  I 
> think we've got something that is a good mix of abstract enough to 
> handle multiple protocols while still providing some added value to 
> applications/plugins that use such apis.
>
> Thanks for the comments.  If you know of good open source and java 
> implementations of SIMPLE/SIP please let us know.

I did not know of any implementations, but a colleague recommended that 
I check out NIST.  They appear to be implementing the relevant JSRs from 
jcp.org to support SIP/SIMPLE.  Their download site is 
http://snad.ncsl.nist.gov/proj/iptel/.  Hope that helps.

> Scott