[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ecomm] Re: An abstract conferencing model 
Scott:

My comments are mixed in. When I get the energy, I'll add another reply trying to characterize my understanding of your approach and raising some questions.

jfp

Scott Lewis wrote:

Hi John,

John F. Patterson wrote:

Scott:

Some comments mixed in, but it does sound like we have similar, though not identical, models.

Some general issues are:
1) How do you represent online presence/awareness in this model? I gather your containers establish shared object spaces through which the presence of a user is signaled by the availability of a proxy object in the shared space. This seems straightforward for conference-based presence. If we want to provide global online presence, do you adopt the attitude that there is a universal container?


No, only a container that contains the others 'interested' in a given other's presence info. If that's everyone (which seems sort of unlikely to me at the app/user level), then it would make more sense to 'jump out' of a conference model, and have some other messaging model for presence info, I suspect. But I'm not sure whether such 'global online presence' would really be user desirable or not, so I'm less concerned about the scalability implications of this approach to dealing with the common case.

OK, I think we agree that stretching the container (conference) model into a global container is probably not the way to go. My impression is that global online awareness is what people are after with SIMPLE. People do not assume that everyone will want to know about everyone else. Thus, subscriptions can keep the amount of messaging down. The goal is a single service for online awareness rather than a fracturing of the world into numerous separate communities of awareness. People who are interested in global awareness assume individuals will subscribe and publish at a home server (email is the analogy) and it will take care of determining which servers should receive your subscriptions. Since the timing requirements on online awareness are less stringent than conferencing, this seems feasible.

I think your approach uses the containers to establish communities of awareness, which is good if we are in the same community. If we are not in the same community, then one of us will need to be in multiple communities, which is probably what all of us will have to do to some degree. If I do not know what community you are in, then I either need a way to look it up or I just can't know about your online presence.

There is a way to think about these two approaches that makes them more or less similar: we can adopt the attitude that a home server is like your primary community and that there is a directory of primary communities (probably needed in either case, if global awareness is the objective.) The main difference that I see is that one approach makes your primary community look global by relaying subscriptions and notifications as needed, while the other leaves it to the client to subscribe to the multiple communities from which online awareness is desired.

This seems a stretch

for what I think of as a conference.


True. I have some difficulty imagining what such an application would be like from the user point of view.

I think we agree that stretching the conference model to embrace global online awareness is a challenge.

2) My impression is that you support shared object spaces. (Do you support nested spaces?) 


Yes, although I haven't found a really good application for it...yet.

I agree that nested object spaces is not a first-order concern. The real question is what is the semantic implied by the parent-child relationship. If it is merely a link, then why bother with containment. Usually, the semantic would be something like "you can't enter one space unless you are already in the other" or "if the parent space goes away, then so do its children" or "the properties of the child space (not its objects) are visible in the parent space".

One example that I have thought about but not implemented is an online casino with multiple gaming tables. The casino is one space that allows lots of people to wander around. The tables are separate child spaces with limited participation. Those in the casino can see some aspects of the gaming tables via the properties of the table itself, but they have to sit down at the table to actually mainipulate its objects.

Within each shared object space, a client learns about and may manipulate the objects within that space. Presence objects are a specialized type of object because they represent the association of the client with the shared object space. As such, they impose a policy that permits only the represented client to actually manipulate the object. The policy regarding visibility of the Presence objects is controllable, such that a standard conference would provide visibility of all presence objects, while an online awareness system would support subscription-based buddy list type awareness. Other objects (components or tools) provide specialized capabilities that usually involve sending a message to all joined clients or changing some shared state that is visible to all joined clients. Is this generally right?


Yes. You are right on. The only thing I would add is that your phrase 'the policy regarding visibility of objects is controllable...' is true, but I would generalize this to 'the policy regarding the object's behavior/code *in general* is controllable'...via the Java 2 protection domain and it's guarantee of component type safety. This is a really nice thing about the java2 security model...it fits very well with the possibility that (untrusted) remote participants might introduce objects of unknown qualities...and each participant can have a group and personal protection domain for that object.

I'm not familiar with the Java 2 security model, but it definitely sounds useful. In a separate post, I'll take a more extensive pass at seeing if I am understanding your model correctly.

3) How do we move towards a common nomenclature?


Well, I would propose we first come up with a generic name for the 'component' or 'conference tool'...since we can then refer to the container for that as [X]Container.

At its core, it seems to me that you have a SharedObjectContainer and SharedObjects. I'm not sure I like these names either, but they seem more precise than container and object per se.

I've used names like [X]Object (like RemoteObject, or ReplicatedObject) but I don't really like these. I've also recently (in the Composent code) used the term 'Stage'...which was used by Matt Welsh in his Ph.D work on SEDA...Scalable Event Driven Architecture.

I'm not familiar with Matt's work, but the term "Stage" has a certain appeal to me. I assume the container is a Stage. This leads me to ask why PresenceObjects aren't Actors and other objects aren't either Props or Scenery. (Is it a Prop if it can be manipulated and Scenery if it is final?) This analogy seems closest to what I think of as conferencing, but doesn't seem quite right for online awareness.


Alternatively, I think it would be a very good idea to connect the ecomm APIs by name directly to the OSGI model, and perhaps extend the OSGI 'Bundle' concept...e.g. DistributedBundle or a shortened version like DBundle.

DBundle
DBundleContainer

Any thoughts about this?

I'm not that familiar with the OSGI model, so it is hard for me to say.

BTW, I think it's probably going to make sense to change the name of this project to something like 'Eclipse Communications Framework' or 'ecf' rather than 'ecomm'. Obviously, at this stage of the project it's a good time to get such names nailed down, and I admit to a certain lack of creativity on my part for ecomm.

I agree that naming is important. It seems to me that you are largely focused on Synchronous Groupware (awareness, chat) rather than Asynchronous Groupware (email, discussion rooms), so I keep wondering why you use such a general term like communications. Putting aside the confusing detail that synchronous groupware is achieved with asynchronous messaging, I wonder whether something more like Synchronous Groupware Framework (SGF) would be appropriate. I'm not sure I am advocating this name, but it has the properties that I would want to see, i.e., an identification of the class of application being supported and an indication that it is a general infrastructure for supporting it.

4)  What's the next exercise?

For my part, I am inclined to keep focusing on the API and leave implementations and applications aside for the time being. I am definitely finding this useful, but it would be nice to know if we are just talking to each other. Is anyone else listening in?


Well, at least we're listening :-). Actually, I've understood from others through correspondence that they *are* reading these posts and some folks have found them useful. I also feel they are useful and so would like to continue them...and yes, I agree the right focus is on the API(s)...because I do believe that the virtualization we're discussing is a potentially highly valuable contribution to be made by this project.

Please others do chime in.

Thanks,

Scott