tgk · May 14, 2014 20:55 · cemerick · May 16, 2014 · tgk · May 16, 2014
diff --git a/quilt_proposal.edn b/quilt_proposal.edn
 ;; These notes describe the snapshots of a shared state between
 ;; pariticipants in a system co-ordinated using CRDT methods, hopefully
 ;; matching the Quilt notes from @cemerick at
 ;; http://writings.quilt.org/2014/05/12/distributed-systems-and-the-end-of-the-api/
 ;; The ambition is to built systems where network failures, replays
 ;; etc. can be safely ignored (instead of just being ignored).

 ;; Maintaining the "timestamps" for the append only database is the only
 ;; thing I feel I don't grok. There are some notes at the end of the
 ;; gist. Hoping for feedback or pointers!

 ;; In a CRDT co-ordinated system, information is only added. We start
 ;; out with an empty shared state

 {}

 ;; A pariticipant adds a facts to the database at time 1

 {:db {1 '(1 2 4)}}

 ;; Some other participant adds a value to the database. We now have a
 ;; database with the time 2.

 {:db {1 '(1 2 4)
      2 '(1 2 4 5)}}

 ;; A participant has a copy of the shared state and knows that there is
 ;; a version available with the time-tag 1. It can therefore add a query
 ;; (idempotentily) to the store

 {:db {1 '(1 2 4)
      2 '(1 2 4 5)}
 :qs #{{:db/version 1, :expr "/sum"}}}

 ;; A process able to fulfil the query picks it up, and adds the result
 ;; of the query back into the shared store (again, idempotently).

 {:db {1 '(1 2 4)
      2 '(1 2 4 5)}
 :qs #{{:db/version 1, :expr "/sum"}}
 :rs {{:db/version 1, :expr "/sum"} 7}}

 ;; Removing values from the database, again, yields a new value

 {:db {1 '(1 2 4)
      2 '(1 2 4 5)
      3 '(2 4 5)}
 :qs #{{:db/version 1, :expr "/sum"}}
 :rs {{:db/version 1, :expr "/sum"} 7}}

 ;; I'm not entirely sure how database versions are co-ordinated. It
 ;; could be vector clocks, it could be sha's of the data in the
 ;; database, or it could be the events sourced for the db. Any feedback
 ;; on this aspect is more than welcome.
	;; These notes describe the snapshots of a shared state between
	;; pariticipants in a system co-ordinated using CRDT methods, hopefully
	;; matching the Quilt notes from @cemerick at
	;; http://writings.quilt.org/2014/05/12/distributed-systems-and-the-end-of-the-api/
	;; The ambition is to built systems where network failures, replays
	;; etc. can be safely ignored (instead of just being ignored).

	;; Maintaining the "timestamps" for the append only database is the only
	;; thing I feel I don't grok. There are some notes at the end of the
	;; gist. Hoping for feedback or pointers!

	;; In a CRDT co-ordinated system, information is only added. We start
	;; out with an empty shared state

	{}

	;; A pariticipant adds a facts to the database at time 1

	{:db {1 '(1 2 4)}}

	;; Some other participant adds a value to the database. We now have a
	;; database with the time 2.

	{:db {1 '(1 2 4)
	2 '(1 2 4 5)}}

	;; A participant has a copy of the shared state and knows that there is
	;; a version available with the time-tag 1. It can therefore add a query
	;; (idempotentily) to the store

	{:db {1 '(1 2 4)
	2 '(1 2 4 5)}
	:qs #{{:db/version 1, :expr "/sum"}}}

	;; A process able to fulfil the query picks it up, and adds the result
	;; of the query back into the shared store (again, idempotently).

	{:db {1 '(1 2 4)
	2 '(1 2 4 5)}
	:qs #{{:db/version 1, :expr "/sum"}}
	:rs {{:db/version 1, :expr "/sum"} 7}}

	;; Removing values from the database, again, yields a new value

	{:db {1 '(1 2 4)
	2 '(1 2 4 5)
	3 '(2 4 5)}
	:qs #{{:db/version 1, :expr "/sum"}}
	:rs {{:db/version 1, :expr "/sum"} 7}}

	;; I'm not entirely sure how database versions are co-ordinated. It
	;; could be vector clocks, it could be sha's of the data in the
	;; database, or it could be the events sourced for the db. Any feedback
	;; on this aspect is more than welcome.