Identify requests and their responses

[chadrik]

One of the most confusing aspects of the protocol description is that it does not clearly specify which messages are requests, and if so, what type of message should be sent in response. It would be good to identify whether something is a request, response, or both, and have hyperlinks to jump between.

[jonnor]

I think each schema of each message should contain some key "expectsReply" with the reply that should be sent.

[ruippeixotog]

For me, the Graph Protocol is particularly confusing on that aspect.

For example, by reading the spec, I understood that the runtime is expected to react to a removenode with a succession of changeedge, removeedge, changenode and finally removenode. What is the rationale behind deleting the metadata of an edge before removing it? I believe noflo-ui takes care of deleting dependent edges/IIPs before removing a node; why is that not expected of every client, requiring the runtime to handle only simple cases? Or assume the runtime takes care of all dependent resources in a removenode, requiring it to reply with a single removenode?

I was also confused with the response to changing the metadata of edges or nodes.

I noticed another related issue, a bit more severe: when "removing an IIP", the spec indicates the runtime "should provide response that iip was removed". The message it expects is a removeinitial command but contains a src field, which is not accepted in removeinitial messages.

The rationale behind the requests and responses/events should be clarified in the spec, so people implementing runtimes have a clear idea of how to handle those cases. My personal opinion is that request message types should not be used also as "notification event" message types, as the contents differ in some cases and drawing that line that would result in a clearer protocol. However, anything that is defined a bit more formally would be great for me! :)

[bergie]

We should add a request ID to every request, and ensure it always gets either a success or error response with a "in reply to".

Messages without "in reply to" should be treated as "signals".

We already have client implementation that does this in https://github.com/flowbased/fbp-client by some heuristics, but actual "in reply to" would make that a lot more robust

[bergie]

Proposal:

• A request should specify its ID:

{
  "protocol": "graph",
  "command": "clear",
  "payload": {...},
  "secret": "xx",
  "requestId": "yy"
}

• A response should specify which request it is for:

{
  "protocol": "graph",
  "command": "clear",
  "payload": {...},
  "responseTo": "yy"
}

• Signals don't include a responseTo