Difference between revisions of "Corona More Generic PCC Manager"

Revision as of 06:17, 12 March 2007

There are two managers now - ContextContainer Manager and Project Container Manager. The difference between them is that Project one introduces methods connected with users (eg. openContainerForMember()). This causes some problems, eg. you need to distinguish whether you want to open CC or PCC.

I think we could use the more generic manager interface for Context Containers only.

ClientContext parameter

Instead of providing a methods openContainerForMember() and closeContainerForMember() we could have a generic method openContainer() which would have a parameter with client context. The client context would be a some kind of properties (name-value). By default the context contains only the client id.

Now, any new context that may want to add something would register with extension point. The project context would simply add property with the user. An other context would add whatever it wants.

On the server side, there need to be something that would make use of the context information. And again the open() method on server side would use an extension point to detect context information consumers. It would pass it there. In project example, the project context would build map of client id to user.

This could look somehow similar to this:

1. Someone calls open() method for a context container.
2. The container manager proxy creates a client context object and looks for the context extenders declared in extension point. Each of them is invoked and has an ability to add its information to client context object.
3. The open method is invoked on the server with the created client context as a parameter.
4. The server side again looks for context extenders and passes the client context object. There should be corresponding context extenders on client and server side. The server side for instance keeps information that given client is a user.

Both client and server side context consumers/fillers could implement the IContextContainerManager interface. So, they could react for any method invoked on the ContextContainerManager.

Event enhancers

As we know, the open() method sends the open event. If we do not have the open() method in project scope, the event would lack the information of the user, who opened the event. But, again with extension points, we can register event enhancers. Event enhancer would be objects that obtain event and adds some information to it, before it is published. They would be done in ContextContainerEventAdmin.sendEvent().

Again in the project context, there would be an event enhancer that sets the user connected with the event.

As a sequence diagram:

1. Some component wants to send an event.
2. The event admin iterates over event enhancers found in an extension point, and gives the event which is about to be broadcasted. The enhancer may for instance add user name parameter, which is defined in project scope. On the server side, the enhancer may take information collected by client context extender. So first the it takes information on user connected by given client id. Then, when open event is sent, it adds user to the event.
3. The enhanced event is broadcasted in corona system.

Team management

One more thing provided by PC Manager over CC Manager are team methods (listActiveMembers(), joinProject(), ...). This functionality can be simply moved to an additional WS endpoint that would provide such functionality. The endpoint would could be defined in container as an repository.