How to specifiy subscription scope?

[enikao]

When a delta protocol client connects to the repository, it might want to define what updates it cares for.

Potential scopes

A Whole repo

Pro:

• Probably useful for processors like incremental validator, auto-fixer, model querier

Con:

• Not useful especially for web clients that don't want to be bothered with updates on the whole repo.

B All nodes of concept X

Pro:

• Might be useful for concept-specific views

Con:

• Close to query (Additional API: Complex queries #39)

C Partitions

Pro:

• Natural entry point
• Would avoid "double request" scenario: 1/ client asks for all partitions via bulk, gets them; 2/ client asks for contents of one partition via bulk, gets all nodes 3/ client subscribes for one of these nodes via delta, gets all descendants again

Con:

• users might run into too large models

D Any node

Pro:

• Very flexible

Con:

E Any node with optional depth

Same as D, but the client can optionally specify a depth parameter (as in bulk retrieve).

Pro:

• Would solve the "I only care about this node as a reference target, not any of its descendants" issue (How to subscribe to reference targets? #268)

Con:

• Few use cases for depths other than infinite or zero

Working assuption: D

Any node can be defined as scope. Scope includes that node and all descendants(children + annotations). Client can subscribe to several nodes.

[dslmeinte]

D = A + B + C + E anyway?

I'm guessing E is most practical as it effectively generalizes A and C but is more flexible, and probably easier to get to perform.

[enikao]

How does D include A? With D, I had to subscribe to every partition to have the same result as A.

[joswarmer]

I would suggest C + D + E (where C is a special case of E)
Maybe also A, as it clearly has use cases, but can also be done in E by subscribing to all partitions, so we do not need it per se.
B is a can of worms that we should not open now.

[enikao]

B is a can of worms that we should not open now.

+1

[enikao]

If we subscribe to a node, which kind of deltas do we get?

• All messages about this node
• Only parts, e.g. property changes, containment changes
  • Weak use case: We show only the name (e.g. in list of partitions, or reference target), then we don't care about containment/reference changes
  • Con: Nodes are very fine-grained, so being notified about all kind of changes shouldn't bother the client too much
• What about deleting the node indirectly? If we remove a node via delta protocol, do we also need to send events for all descendants? #286
• What about moving this node? That might be only a change to its parent
  Example: Node A contains node B. my client is subscribed to B but not A.
  If B is moved to a different parent C, is my client notified? How about moving B to a different containment of A?
  Option 1: Yes, B is notified
  Option 2: No, my client needs to subscribe to A. Downside: my client also gets notified about all siblings (and their descendants) of B
• If something is moved in/out as a child of a subscribed node, do I get notified?
  Change of feature of subscribed node, so I should be notified
• If model shape changes, does the repo automatically update subscribed nodes or does the client need to?
  --> Potentially lots of round trips
  Probably repo should update subscription scope

[enikao]

From Modelix' experience, it's very hard to maintain a consistent state of a partially subscribed model on the client.

There's also a redundancy in your implementation: Both your scope description and the actual code that processes the model need to know about the required scope.