Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [corona-dev] Ref count for container. 
Hi Folks,
Note that the ECF shared object API provides for group membership notifications. That is, internal to the generic shared object container is a 'group membership manager' which tracks clients (by clientID) and sends/receives notifications of client arrival and departure. The group membership manager's failure detection allows other clients to be reliably notified if a given client crashes, or if there is a network partition.
These group membership changes can be easily mapped to other user state (e.g. user presence, project state, workspace state, etc), if the client's online/offline state is reported in a timely fashion (with app-specified keepalive/timeout)...or to logic for automatic reconnect.
If application code is written as shared object instances, they will be automatically notified about clients (identified by clientID) coming and going. They simply need to respond to the delivery of IContainerConnectedEvent/IContainerDisconnectedEvent to the ISharedObject.handleEvent method.
Underneath the sharedobjectcontainer is a transport-level protocol (see org.eclipse.ecf.provider.comm package) that is currently implemented with 

a) a simple socket-level message protocol...aka 'ecftcp'
b) ActiveMQ (org.eclipse.ecf.provider.jms)
c) JXTA (org.eclipse.ecf.provider.jxta)
It's possible to insert some other transport (e.g. SOAP) underneath ('d', etc) and use that instead. This would be done simply by implementing a new ISharedObjectContainer instance that extends ClientSOContainer, and overrides ClientSOContainer.createConnection() to return an implementation based upon the transport of one's choosing.
The intention and result is that then applications that require reliable group membership info can get it in a transport-independent way and use it in any way desired. 

If more info or pointers to code examples is desired, please let me know.

Scott


Marcin Okraszewski wrote:
At project level there would be a component that would have a set of client IDs for a user. When the set becomes empty, the offline message would be sent. 

Don't know exactly what your are asking about semantics. In general then:
- open / close would indicate that a client (a software instance) opened / closed container - online / offline would indicate that user opened a container for the first time; offline user closed container in all his instances 

Marcin


Everitt, Glenn wrote:

What keeps track of Clients - since a ClientID may reference many
Containers.  If I understand...

So, do we need to define semantics for? Client - open, close
User - on, off
Container - open, close
User in a Container - yes, no

-----Original Message-----
From: corona-dev-bounces@xxxxxxxxxxx
[mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: Wednesday, March 14, 2007 8:55 AM
To: Corona development
Subject: RE: [corona-dev] Ref count for container.

+1 for using an ID, not user.

The ref count was / is intended to identify the number of open requests
for a specific container.  It is possible that a component (non-user)
has opened a container.

-----Original Message-----
From: corona-dev-bounces@xxxxxxxxxxx
[mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Everitt, Glenn
Sent: Wednesday, March 14, 2007 8:47 AM
To: Corona development
Subject: RE: [corona-dev] Ref count for container.

...deleted stuff
*/[Glenn] I thought we were only interested in other Users that were active in my Container - since all of the views are within in the context of a container. I'm only interested in users that have the same container open as I do. This approach gives me the ability to NOT
be available to others in a Containers I don't have open, even though I may be "online"/* 



[Marcin] You have two computers. You may want to open the same container
twice, have two clients open for the same team member. Then when you close one of the containers, the "close" event is sent. With current semantic, this would mean you are offline, but you still have one instance running. It is not about being online in an other container. 

[Glenn]  OK - then do we need to reference count users?  Or should we do
what you suggested earlier and keep track of a ClientID and an
associated User?  That would mean "Close" is for a Container with
associated with a ClientID.  We still need to know if a user is still
available in a particular Container...

So, do we need to define semantics for? Client - open, close
User - on, off
Container - open, close
User in a Container - yes, no
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it. _______________________________________________ 
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it. _______________________________________________ 
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. _______________________________________________ 
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. _______________________________________________ 
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev

Back to the top