[news.eclipse.technology.ecomm] Re: An abstract conferencing model

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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.

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.

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

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

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

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.

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?

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.

> 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