Content
View differences
Updated by Jens Ulferts over 9 years ago
### Problem
Updating a work package in OpenProject can cause other work packages to be updated as well. Examples for that are changes to
- dates
- parent
- children
- time
(please see children for further examples)
If only one work package is displayed, everything is fine. But when a set of work packages are visible (or stored on the client) and an update changes the data of the work packages on the server, those changes should be reflected on the client. Otherwise, the information has become outdated without the user knowing it.
### General problems
- Have to work with work packages being updated while the user might be editing it.
### Approaches/Ideas
<ins>Let client update all work packages it has stored</ins>
After an update, the client fetches all work packages it has locally. This can be done in a way that is invisible to the end user.
- Pro:
- Very simple on the server side (nothing to do)
- Moderate complexity on the client side
- Con:
- Inefficient as all work packages have to be updated
- Only own changes trigger an update by the client. That way, changes by others are only recognized after an own update and once the work packages are updated the end user can not differentiate between changes caused by himself and those caused by others.
- Overhead of extra api request.
<ins>Send url of updated work packages as response to update</ins>
As part of the response, the server sends a list of work packages that have been updated along with the intended update target.
- Pro:
- Moderate complexity on the server side
- Moderate complexity on the client side
- Only need to fetch a limited amount of work packages, not every work package displayed.
- Will enable informing the user of changes to work packages not currently displayed but that might be of importance.
- The client can decide if the update information is important and only then fetch the updated work packages.
- Con:
- Have to adapt the api response, maybe introduce a <code>Batch</code> or <code>Update</code> resource which includes the more complex update information
- Have to rework the server update mechanisms to no longer use <code>after\_save</code> hooks so that the server is becoming aware of all updated work packages so that the information can become part of the response.
- Only own change trigger an update so that changes by others are not noticed.
- Needs to fetch work packages in separate request as there is currently no api end point to get a list of specific work packages.
- Need to update all create/update endpoints to recreate consistency.
<ins>Send all updated work packages as response to the update</ins>
As part of the response, the server sends a \`Collection\` resource including all WorkPackages updated along with the intended update target.
- Pro:
- Moderate complexity on the server side
- Moderate complexity on the client side
- Does not need to trigger a separate request as the updated work packages are delivered right away.
- Will enable informing the user of changes to work packages not currently displayed but that might be of importance.
- Can reuse the \`Collection\` resource.
- Con:
- Have to rework the server update mechanisms to no longer use <code>after\_save</code> hooks so that the server is becoming aware of all updated work packages so that the information can become part of the response.
- Only own change trigger an update so that changes by others are not noticed.
- Need to update all create/update endpoints to recreate consistency.
<ins>Websockets between client and server</ins>
The client has a websocket to the server by which information can be transmitted at all time.
- Pro:
- Client can be updated of changes made by other users as well. No update by the user necessary.
- Can simply transmit every updated resource via the socket or reuse the \`Collection\` resource.
- The websocket can be reused for other use cases as well.
- Api itself can remain unchanged.
- Con:
- High complexity for server and client
- New technology in OpenProject
- Unclear if supported by every infrastructure (proxy)
- Have to rework the server update mechanisms to no longer use <code>after\_save</code> hooks so that the server is becoming aware of all updated work packages so that the information can become part of the response.
Updating a work package in OpenProject can cause other work packages to be updated as well. Examples for that are changes to
- dates
- parent
- children
- time
(please see children for further examples)
If only one work package is displayed, everything is fine. But when a set of work packages are visible (or stored on the client) and an update changes the data of the work packages on the server, those changes should be reflected on the client. Otherwise, the information has become outdated without the user knowing it.
### General problems
- Have to work with work packages being updated while the user might be editing it.
### Approaches/Ideas
<ins>Let client update all work packages it has stored</ins>
After an update, the client fetches all work packages it has locally. This can be done in a way that is invisible to the end user.
- Pro:
- Very simple on the server side (nothing to do)
- Moderate complexity on the client side
- Con:
- Inefficient as all work packages have to be updated
- Only own changes trigger an update by the client. That way, changes by others are only recognized after an own update and once the work packages are updated the end user can not differentiate between changes caused by himself and those caused by others.
- Overhead of extra api request.
<ins>Send url of updated work packages as response to update</ins>
As part of the response, the server sends a list of work packages that have been updated along with the intended update target.
- Pro:
- Moderate complexity on the server side
- Moderate complexity on the client side
- Only need to fetch a limited amount of work packages, not every work package displayed.
- Will enable informing the user of changes to work packages not currently displayed but that might be of importance.
- The client can decide if the update information is important and only then fetch the updated work packages.
- Con:
- Have to adapt the api response, maybe introduce a <code>Batch</code> or <code>Update</code> resource which includes the more complex update information
- Have to rework the server update mechanisms to no longer use <code>after\_save</code> hooks so that the server is becoming aware of all updated work packages so that the information can become part of the response.
- Only own change trigger an update so that changes by others are not noticed.
- Needs to fetch work packages in separate request as there is currently no api end point to get a list of specific work packages.
- Need to update all create/update endpoints to recreate consistency.
<ins>Send all updated work packages as response to the update</ins>
As part of the response, the server sends a \`Collection\` resource including all WorkPackages updated along with the intended update target.
- Pro:
- Moderate complexity on the server side
- Moderate complexity on the client side
- Does not need to trigger a separate request as the updated work packages are delivered right away.
- Will enable informing the user of changes to work packages not currently displayed but that might be of importance.
- Can reuse the \`Collection\` resource.
- Con:
- Have to rework the server update mechanisms to no longer use <code>after\_save</code> hooks so that the server is becoming aware of all updated work packages so that the information can become part of the response.
- Only own change trigger an update so that changes by others are not noticed.
- Need to update all create/update endpoints to recreate consistency.
<ins>Websockets between client and server</ins>
The client has a websocket to the server by which information can be transmitted at all time.
- Pro:
- Client can be updated of changes made by other users as well. No update by the user necessary.
- Can simply transmit every updated resource via the socket or reuse the \`Collection\` resource.
- The websocket can be reused for other use cases as well.
- Api itself can remain unchanged.
- Con:
- High complexity for server and client
- New technology in OpenProject
- Unclear if supported by every infrastructure (proxy)
- Have to rework the server update mechanisms to no longer use <code>after\_save</code> hooks so that the server is becoming aware of all updated work packages so that the information can become part of the response.