{"action":"created","issue":{"url":"https://api.github.com/repos/nebtex/delta/issues/18","repository_url":"https://api.github.com/repos/nebtex/delta","labels_url":"https://api.github.com/repos/nebtex/delta/issues/18/labels{/name}","comments_url":"https://api.github.com/repos/nebtex/delta/issues/18/comments","events_url":"https://api.github.com/repos/nebtex/delta/issues/18/events","html_url":"https://github.com/nebtex/delta/issues/18","id":263797144,"number":18,"title":"CRDTs","user":{"login":"gritzko","id":81581,"avatar_url":"https://avatars2.githubusercontent.com/u/81581?v=4","gravatar_id":"","url":"https://api.github.com/users/gritzko","html_url":"https://github.com/gritzko","followers_url":"https://api.github.com/users/gritzko/followers","following_url":"https://api.github.com/users/gritzko/following{/other_user}","gists_url":"https://api.github.com/users/gritzko/gists{/gist_id}","starred_url":"https://api.github.com/users/gritzko/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gritzko/subscriptions","organizations_url":"https://api.github.com/users/gritzko/orgs","repos_url":"https://api.github.com/users/gritzko/repos","events_url":"https://api.github.com/users/gritzko/events{/privacy}","received_events_url":"https://api.github.com/users/gritzko/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2017-10-09T06:43:40Z","updated_at":"2017-10-10T00:25:33Z","closed_at":null,"author_association":"NONE","body":"Hi Cristian!\r\n\r\nAre you aware of CRDTs?\r\nI believe, they fit into your superposition model :)"},"comment":{"url":"https://api.github.com/repos/nebtex/delta/issues/comments/335324530","html_url":"https://github.com/nebtex/delta/issues/18#issuecomment-335324530","issue_url":"https://api.github.com/repos/nebtex/delta/issues/18","id":335324530,"user":{"login":"criloz","id":1408540,"avatar_url":"https://avatars1.githubusercontent.com/u/1408540?v=4","gravatar_id":"","url":"https://api.github.com/users/criloz","html_url":"https://github.com/criloz","followers_url":"https://api.github.com/users/criloz/followers","following_url":"https://api.github.com/users/criloz/following{/other_user}","gists_url":"https://api.github.com/users/criloz/gists{/gist_id}","starred_url":"https://api.github.com/users/criloz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/criloz/subscriptions","organizations_url":"https://api.github.com/users/criloz/orgs","repos_url":"https://api.github.com/users/criloz/repos","events_url":"https://api.github.com/users/criloz/events{/privacy}","received_events_url":"https://api.github.com/users/criloz/received_events","type":"User","site_admin":false},"created_at":"2017-10-10T00:25:33Z","updated_at":"2017-10-10T00:25:33Z","author_association":"OWNER","body":"@gritzko thanks again !!!!, you comment has been really helpful\r\n\r\nafter doing some reads, the best approach that I can think of is add to each message an overhead of 16 bytes that will represent the time on nanoseconds\r\n\r\nfor the **Idempotence** if two message have the same timestamp in the same superposition/resource they will be the same \r\n\r\nfor **Commutativity**,  the strategy will create a fork of the superposition if a message comes with a timestamp between the first and the last message like I show in the image. \r\n\r\nthis will for what I plan to do because.\r\n\r\n1. I don't want to modify message that already exists in the superposition, some running computations can be using them and they should be locked till those computations end. \r\n\r\n2. a computation should always receive the previous and the latest version of a superposition, this helps the computation to decide how the delta affect it,  so after the following computation in the cycle ends, it will be safe to delete the incoherent branch. \r\n\r\n![crdt](https://user-images.githubusercontent.com/1408540/31363582-c81a0184-ad24-11e7-9811-15b7cedf7e4a.png)\r\n\r\nan issue with this model can arise due that the client should compact the superposition to a single message every other time according to memory usage or fragmentation while the frequency of this process can be low, there is still some margin for incoherence,  in those case the compacted message should take the timestamp of the latest message used in  the compaction,  and if it detects new messages with lower timestamp then the client should reconcile with the backend,  using a request/response model, after the reconciliation any message with timestamp lower that the superposition should be ignore\r\n\r\n\r\nwhat do you think about this?"}}
{"actor":{"display_login":"criloz"}}