[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ecomm] Re: What about SIP/SIMPLE? 
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.

jfp

Scott Lewis wrote:

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

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?

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?


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


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.


<stuff deleted>