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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

John F. Patterson wrote:
> Scott:
>
> There are a few embedded comments, but I think we are reaching the point 
> where I need to lay out the types of interfaces that I am accustomed to 
> talking about and we need to see if they map onto the kinds of 
> interfaces you're used to talking about.  I'll start that up in a new 
> top-level thread, however.

OK, sounds good.  If you want an example of the kind of interfaces I've 
been thinking about, please feel free to take a look at the (source) 
code available at

http://www.composent.com/plugins

Obviously, these won't be exactly the same for this project, but like 
everyone else I'm influenced by previous approaches to solving these 
problems.

> <stuff deleted>
> >
> I suspected your use of Identity services subsumed directory services 
> such as LDAP.  You seem to have generalized it to include the 
> identification of things other than people and groups.  I'm not used to 
> that, but it doesn't seem too problematic.  I assume your notion of 
> Identity services also provides for authentication.  Is that correct?

Yes.

> > RE: conferencing...my interpretation of this is captured (I think) by 
> > 'group' communications model...e.g. publish and subscribe models of 
> > messaging.
>
>
> While I do think of conferencing as a "group communication" capability, 
> I don't tend to think of it as pub/sub.  One could think of "joining" 
> the conference as subscribing for notifications from the conference, but 
> it is not usually talked about that way.  There are many different names 
> used for the beast -- session, conference, meeting, place, room -- but 
> it is usually a multi-point releationship among a set of communicating 
> entities.  At a first order, one can join the multi-point relationship, 
> send to all the participants, receive from the participants, and leave 
> the multi-point relationship.   Would you call  this subscribing, 
> publishing, receiving a notification, and unsubscribing respectively?

I would currently refer to it as 'joining', 'sending to', 'receiving 
from', and 'leaving' a distributed container.

My reference to pub/sub was implementational (not a word, I 
know)...pub/sub messaging systems (e.g. JMS, etc) can support such a 
pattern very naturally.

> > 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).
> Agreed, but presence/awareness does not imply a multi-point 
> relationship.  Also, the information communicated is about the state of 
> some object; it is not thought of as a message from another entity as in 
> conferencing.  I realize that these distinctions are subtle and do not 
> always imply different underlying technologies.  I'm just trying to 
> reveal the programming model that I am accustomed to and why I think of 
> conferencing and presence/awareness as distinct services.

I guess implicitly I've come to think of presence as just another 
example of 'state sharing', where the state being shared is state of 
another person.  Of course this state sharing is special for UI/users, 
and the technical mechanisms to support it have to be complete (e.g. 
failure detection and group membership so that failures can be displayed 
to user properly).  If components have the ability to share arbitrary 
state with arbitrary (1 or more) others (based upon trust relationship 
between users), then presence communication can naturally be implemented 
as a component.

RE: programming model...I would be interested to hear your perspective. 
    I'm not necessarily committed to model above, but it has worked for me.

> > > 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).
> Two comments:
> 1)  I think I am beginning to understand your approach.  You really have 
> two distinct services:  asynchronous messaging (for push-related 
> capabilities) and identity services.  In your componentry plug-in you 
> have placed the abstract interfaces, events, and exceptions that define 
> the API.  Does this API package provide the interfaces for both services 
> or only the asynchronous messaging services?

With my previous implementation there are two APIs exposed by two 
plugins...identity and asynchronous messaging.  This doesn't mean that 
they couldn't be combined, but I've come to think of them as logically 
separate.

> 2)  I might not have explained what I meant by component very well.  It 
> is not just that these things -- app sharing, chat, voip, etc -- have a 
> common base, but that they can be added into and dropped from 
> conferences.  In other words, the multi-point relationship object, let's 
> call it a conference, might contain a chat component to start with, but 
> later add a voip component to enable voice.  The chat and voip 
> components are "inheriting" (in a run-time sense) the multi-point 
> relationship implied by the conference object.  It is the conference 
> object's job to manage the mutli-point relationship and it is the 
> component's job to do the communication.

Yes, I agree with you completely.  Run-time component distribution and 
instantiation definitely makes sense to support dynamically changing 
needs for conferences/collaborations.  This is definitely one of the 
features that I have emphasized in my previous work (run-time 
manipulation of app-level features).

> > > 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.
> I'm not entirely sure what's best here either.  I can see the appeal of 
> a common abstraction that handles both conferencing and 
> presence/awareness.  On the other hand, I have different user models for 
> these two capabilities.  Should an API strive for simplicity through a 
> reduced number of abstractions or through using familiar constructs?  An 
> interesting design tradeoff.

Agreed.  It may very well be 'better' at this point to increase the 
complexity of an API because many have gotten used to presence being 
provided via a protocol-level API.

Thanks for the questions.  I appreciate your comments...I think this 
will help the design and development effort tremendously.

Scott


> > > <stuff deleted>