Broken roundtrip, due to inconsistent topic_guids

[jasollien]

Moving from file based to API-based communication, we moved all logic for "topic_guid" generation from the client to the server. This works nice if the client don't supports file export or import. However, for those who do, server generated guids causes some problems with synchronization.

This:
1: User creates a topic in a client (client generates a topic_guid "guid1"
2: User exports a BCF-file of this topic (with topic_guid "guid1"
3: User syncs this topic to a server (note, server will create a new topic_guid "guid2"
4: Another user makes a comment in the BCF-file in another tool, and does a new export: "BCF-file 2"

After this step, the following scenarios will be broken.
5-1: User imports either the BCF-file, or "BCF-file 2" to the server

• guids don't match, and a new topic will be created on the server instead of merging with the actual

5-2: User imports either the BCF-file, or "BCF-file 2" back to the client

• guids don't match, and a new topic will be created on the client instead of merging with the actual

5-3: User makes a new comment in the client, and exports a new BCF-file "BCF-file 3", and imports that in the other tool

• guids don't match, and a new topic will be created in the other tool instead of merging with the actual

In order to solve these problems, I suggest this change in the documentation: #192

Changes will be backwards compatible, both for client and server. When implemented both from the client and the server side, the problems above will be solved

[jasollien]

Agreed fix: #192

Available in release_2_2.

[AlainBolduc]

One problem I see with this approach is the fact that the client may ask to create the same resource twice, providing an existing guid to the server.

I would remove the "The server may ignore the guid and create it's own". I think it opens the door to a bunch of problems. If the client specifies a GUID, the server must try to create the topic (or whatever object) and refuse to serve the request if there is a conflict

I think we should specify how the server is supposed to react in this case.

In my opinion, the server should the server return a 409 (Conflict) error code, which is usually what other system do. In that case, the client application can decide either to perform a PUT request to update the existing topic, or perform a POST without specifying a GUID

[ykulbak]

@jasollien can you please add clarifying comments to the documentation in the spirit of @AlainBolduc comment. The GUID provided by the client should be unique in the context of project (it's not required for it to be server-unique).

[ykulbak]

Accepted and closed by #192 after a discussion in the open CDE hackathon about the concerns raised in #238