|
|
| Line 1: |
Line 1: |
| − | I think that for a running freeplane instance there should be no big difference whether it is connected to another freeplane instance or to a server.
| |
| | | | |
| − | * When the connection is established, the connected instance should get a copy of the edited map.
| |
| − | * Afterwards editing can happen on all instances simultaneously.
| |
| − | * All own editing events should be sent to another instance or to the server.
| |
| − | * All incoming events should be processed and merged into the edited map.
| |
| − |
| |
| − | We should decide what kinds of events should be exchanged.
| |
| − |
| |
| − | We could transmit user actions (AFreeplaneAction) like FreeMind, but I think there is no need to serialize the actions because
| |
| − | * we already have mechanism for serializing the map content, and
| |
| − | * it actually does not matter what user action generated the map change.
| |
| − |
| |
| − | Therefore I suggest to use as a content of each editing event
| |
| − | * either a complete content of the changed nodes, or
| |
| − | * a complete content of the changed extensions, or
| |
| − | * a diff between the serialized content before and after the change.
| |
| − |
| |
| − | Content can be both text or binary. For the pure map content itself XML seems to be fine,
| |
| − | if we want to synchronize another contents like images or pdf there should be ways to transmit them too. The framework should not be limited to only XML content, but I think XML is enough for the first iteration.
| |
| − |
| |
| − | Currently the changes node is not always explicitly known: if an action changes an extension which manages their viewers itself, it does not have to know what node it belongs to.
| |
| − |
| |
| − | All node extensions should know their host nodes for creating an editing event for them.
| |
| − | It could be easily done by introducing an interface like
| |
| − |
| |
| − | INodeExtension extends IExtension
| |
| − | {public NodeModel getHostNode(); public void setHostNode(NodeModel node); }
| |
| − |
| |
| − | and changing node add/remove extension methods so that extensions always know their hosts.
| |
| − |
| |
| − | The server used to connect multiple users should
| |
| − | * have an actual map copy,
| |
| − | * send it to the new connected instances,
| |
| − | * broadcast editing event coming from one instance to all other connected instances,
| |
| − | * actualize the own map version
| |
| − | * manage users and connections
| |
| − |
| |
| − | I think that the server implementation can use parts of the freeplane implementations even if it is closed source: GPL does not enforce anyone to distribute the code in any way. It applies only if somebody wants to distribute the program.
| |
| − |
| |
| − | Some open questions
| |
| − | * If the outgoing and incoming events try to change the same map element in different ways, how to resolve the conflict?
| |
| − | * What happens if user changes the current map?
| |
| − | * Can connections for multiple maps be open at the same time?
| |
| − | * Should undo / redo operations be handled directly by server?
| |
