Corona Design Container Editing

Context Container Editing

The Context Container holds references to all the Repositories known by the container. The Context Container is shared with all of the users in a workgroup.

• All workgroup members in the Context Container Team Member repository have access to the Container definition.

• The Context Container is stored on the Corona Server.

• The Container Context should expose a web service interface so that it can be edited by authorized remote users in the workgroup.

• Authorized users in a workgroup should be allowed to add / remove repository defintions in the Context Container

• The Corona Container Editor should use the Web Service interface to modify the Container definition

• More than one user at a time should be able to edit the Context Container.

• The Context Container should send notifications that the Container has been changed so that Corona Client can update views using information from the Container

• Should we allow a Container to edited by a Corona Client when NOT connected to the Corona Server hosting the Context Container?

• If we do how should resolve potentially conflicting changes?

If you allow off-line changes to the container contents (i.e. changes where conflicts can't be immediately detected/rolled back) then it will be necessary to have some synchronization protocol that can be applied later (e.g. after rejoining) to resolve conflicting changes. Further, it will also be necessary to have some structured versioning (e.g. jackrabbit or other versioning repository) so that sufficient info is retained to implement such a synchronization protocol -- Scott Lewis

Thanks Scott - The Container is an SDO object. The SDO specification mandates that a change summary is kept. I believe EMF/SDO does support creating the Change Summary. However, EMF doesn't provide any help using the Change Summary to handle Synchronization. So, we would have to write the synchronization code using the Change Summary. If anyone has found any information about EMF/SDO Change Summary support please let me know. My only hesitation in relying on the SDO Change Summary is if we needed to change the implementation away from EMF/SDO because it won't scale. - Glenn Everitt

Hi Glenn. You say: 'If anyone has found any information about EMF/SDO Change Summary support please let me know'. We (ECF) used the EMF/SDO change summary to implement the 'graphshare' example application for ECF. We did pretty much exactly what you are suggesting...used EMF/SDO model change notifications to produce an SDO change summary...serialized that out using ECF shared object API...sent message(s) with change summary to remotes...deserialized using ECF shared object API...passed to EMF/SDO to apply the changes. This worked fine for a simple shared graphical editor BUT it doesn't fully deal with the problems associated with offline operation...as there is still the need to serialize simultaneous changes (e.g. on a server or on clients) and then store them away somewhere for later application for offline participants. In the case of our graphshare example app, we always took as authoritative the copy that was available from the peer that *started* the graphshare. This worked OK, but meant that offline changes by anyone else were essentially lost. RE your statement: 'My only hesitation in relying on the SDO Change Summary is if we needed to change the implementation away from EMF/SDO because it won't scale'...I'm not sure what your concern is here about EMF/SDO scaling...what scaling aspect are you concerned with? (e.g. server storage/server bw, etc?). - Scott Lewis

My first impression was that you wanted to make specialized services for instance to add repository. But, fortunately, it seems we are going into sending changes done on local copy. Just to support it - even if we add specialized services to add service there still might be a conflict. If two users add a repository we would add both of them. But it might be THE SAME repository - conflict. But reading an article about SDO I had an impression that it has a naive lock - there is version number in SDO object. If there is concurrent change detected any second change to the same version is rejected. That would also mean that automatic merge isn't possible. But seems like Scott's experiences shows that you can override this behavior. - Marcin Okraszewski

Hi Marcin. I don't remember SDO having any locking/synchronization built in (at least at the time we used it). We implemented our own rules/protocol for handling concurrent changes. Things could have changed by now, but it's been months since I looked at SDO. - Scott Lewis