Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Corona Design Container Editing"
(→Context Container Editing) |
(→Context Container Editing) |
||
| Line 21: | Line 21: | ||
{{CommentBox|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}} | {{CommentBox|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 }} | ||
Revision as of 14:18, 29 January 2007
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 }}