Operations in the domain model: Basic concepts

The org.polymap.core.operation package uses the Eclipse IUndoableOperation system to put operations that change the domain model of the application (org.polymap.core.project? and features) inside single, undoable operations.

While the basics are similar to uDig, there are differences:

  • Session singleton vs. VM singleton. As a desktop app the uDig code depends on the VM singleton pattern. For a server side app we need session singletons.
  • No multi-user. There is no multi-user or propagation concept in uDig.

How to organize collaboration?

The big challenge for us is to provide a system that allows users not just to work with geo data but to collaborativelly working together. There are 4 different levels of collaboration we are going to address with POLYMAP3:

1. Ad-hoc data workbench

Somewhat similar to what uDig provides ("desktop internet GIS") - but on the browser. POLYMAP will probably not reach the level of GIS functionality uDig or other desktop GIS solutions provide. Browser is first prio here. On the other hand OpenLayers? does a tremendous job on bringing GIS functionality to the browser. So the Ad-hoc data workbench is the as-much-as-possible POLYMAP3 "web internet GIS".

2. Propagation of results to other users

Working with the ad-hoc workbench changes the domain model of the system. That is structural information (Map and Layer, see org.polymap.core.project?) and geo features. Changes are encapsulated inside operations (org.polymap.core.operation). Besides undo/redo, operations are also used to propagate changes to other users. Propagation has 2 stages:

  • inform the user that another user is about to change data; decorate these features in the UI
  • allow to add a commit message to every change to help other users to understand what's going on
  • inform the user that another user has changed data and allow to incorporate the results

Just reloading the domain model from the persistent storage does seem to be an option. It would force all users to reload their entire workbench on every change any user has commited. This would probably break the workflow of the users. Not completely sure here. We have to discuss this a bit more. Another point to discuss and elaborate on is the way how users get informed by the UI about the (2 stages) of propagation.

3. Communication tools to organize propagation

The changes are floating between the users now - and probably are confusing (other) users. We need a way to enrich change sets with information that help users to understand whats going on and who is working on what data. Some kind of a commit message. Users can now find who is working on the data, how long and for what reason.

4. Collaborativelly work together on the same data

On top of that information they can adjust, tune and vote on their work. Some kind of hosted communication associated to the items could support this. Maybe a chat system associated to each item (Map, Layer, features). This could also help to document the change history and aditional information of each item.

Trac Appliance - Powered by TurnKey Linux