First steps on delta protocol connection

[enikao]

We assume a stateful, bi-directional connection between client and repository

1. Client connects to repository with a clientId (same as for bulk protocol)
2. Client tells repo the subscription scope (How to specifiy subscription scope? #269)
3. Repo sends all nodes in scope as chunk to client.
4. Repo assures to send all changes on any node in scope based on the state from step 3.

Rationale for 3.: Most clients would be interested the nodes in scope.
The client could also request the nodes in scope via bulk protocol. However, using two different protocols always leaves a potential gap: If the client first requests the contents via bulk at time 1, and then subscribes at time 2, it might miss delta updates that happened between 1 and 2.
If it first subscribes at time 3, and then requests via bulk at time 4, it might receive delta updates that are already included in the retrieved bulk contents. It might be hard for the client to decide whether such an update can be ignored.

[dslmeinte]

I think connections between a client and repository should probably be quite “conversational”, with messages like (client:) “subscribe to partition <P_1>”, “unsubscribe from <P_2>”, (repo:) “hey, partition <P_3> got created”, etc.

[joswarmer]

See #274 of a potential way to close the gap.

[dslmeinte]

See #274 of a potential way to close the gap.

Yeah, but I think messages to the repo {c|sh}ould be quite intentional, so not “if I request all deltas from time onwards I'll effectively have changed scope”.

[enikao]

Point 3. above could be alleviated by #68