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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

John F. Patterson wrote:
> 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
<stuff deleted>
> > 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.  

Actually, I don't think these are very far from one another (but correct 
me if this interpretation is incorrect).  'Identity' is meant to provide 
a common way to identify processes, people, and components in a 
distributed application...very similar to 'directory services' when a 
distributed service (i.e. directory service like LDAP) is responsible 
for managing namespaces and instances of 'users' and 'services'.

RE: conferencing...my interpretation of this is captured (I think) by 
'group' communications model...e.g. publish and subscribe models of 
messaging.

RE: presence/awareness services...to me, this is a consequence of having 
users identified in the way that processes and services are...then state 
information (presence info) can be communicated among identified users 
as per application level needs (e.g. IM notions of presence, more 
extended notions of presence, etc).


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

Yes, actually.  In the implementation that I've created, 'components' 
are things like app sharing, chat, voip, etc.  All of these components 
extend a basic 'component' class(es) that 'lives' in a distributed 
container context, and is able to message replicas of itself and/or 
other components within that container (via communications primitives).

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

Well, this isn't etched in stone by any means...but with that 
caveat...awareness/presence is just a specific service provided by a 
component that represents the state information associated with a given 
user (online/offline/busy/working on projects/etc).  This component uses 
the same set of primitives exposed to other components as described 
above to convey presence changes for a given user.  Not the only way to 
do it of course.


> <stuff deleted>

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

Thanks very much. I'll take a look right away.

Scott