Fix messageKind field for request messages of queries to *not* have the Request suffix

[dslmeinte]

Fixes #274

[enikao]

I was not aware we wanted to change that? The json schema includes the Request suffix.

[dslmeinte]

I was not aware we wanted to change that? The json schema includes the Request suffix.

Isn’t the JSON Schema then not also wrong? Or else I don’t know what was incorrect in the first place.

[enikao]

I agree. IMHO, both JSON and TS was correct (and matches C#).

The confusion was between the technical name of queries in the spec not containing any suffix, and the names in JSON/TS/C# do contain a suffix. We resolved that confusion by the discussion that this JSON is geared towards WebSocket, a protocol that doesn't support synchronous request/response messages. Thus, we have to simulate it by splitting up the XxxQuery from the spec into XxxQueryRequest and XxxQueryResponse.

@dslmeinte @joswarmer Does this fit your understanding?

[dslmeinte]

I agree. IMHO, both JSON and TS was correct (and matches C#).

The confusion was between the technical name of queries in the spec not containing any suffix, and the names in JSON/TS/C# do contain a suffix. We resolved that confusion by the discussion that this JSON is geared towards WebSocket, a protocol that doesn't support synchronous request/response messages. Thus, we have to simulate it by splitting up the XxxQuery from the spec into XxxQueryRequest and XxxQueryResponse.

@dslmeinte @joswarmer Does this fit your understanding?

I think it does. So, we just need to add wording to the specification that mentions that the technical name is not necessarily going to be the value of the messageKind, owing to sync vs. async?

[enikao]

I'd argue that's covered by https://lionweb.io/specification/delta/delta-api.html#out-of-scope

We would need to have a proper "binding spec" to WebSocket, which I think we said we won't do.
I don't think it makes sense to say "your binding may vary in these ways" -- we cannot predict them.
(E.g. some binding might require messages to start lowercase, or be shorter than 32 characters, or only use numbers as identifier, or any other kind of limitation.)

[joswarmer]

I think it does. So, we just need to add wording to the specification that mentions that the technical name is not necessarily going to be the value of the messageKind, owing to sync vs. async?

We are defining properties for messages, so it makes sense to specify the messageKind property as well, as we already do for Commands. I think we should do this for Queries as well, certainly if the are implemented using async web-sockets.

Looking at the three implementations we have (typescript., C#, server), we all have added this exact property. So let's make it official. And explicitly stating that the value of this property is equal to the technical name ensures that various implementations will actually work together, which is the end objective of LionWeb.

Even then different implementations may use different technical means to send messages (sync and/or async) to each other , but the message itself is fully specified and identifiable. There is no need to derive the "message kind" from the technical protocol.

If we do not use the technical name as the value for messageKind property, what then is the purpose of this technical name?

Responses have no technical name in the spec, only requests have. We can specify that the technical name (thus the messageKind) of a Response message is the technical name of the Request + "Response"). Or we can specify both technical names explictly.

I'd argue that's covered by https://lionweb.io/specification/delta/delta-api.html#out-of-scope

In that case, why do we have the messageKind property on all Command definitions?

[joswarmer]

I was not aware we wanted to change that? The json schema includes the Request suffix.

Isn’t the JSON Schema then not also wrong? Or else I don’t know what was incorrect in the first place.

Yes, it's wrong as well.

[enikao]

I actually like the difference names for the conceptual, synchronous, request/response XxxQuery and the request-only, asynchronous, implementation-specific XxxQueryRequest. Makes it easier to distinguish them.

[joswarmer]

I actually like the difference names for the conceptual, synchronous, request/response XxxQuery and the request-only, asynchronous, implementation-specific XxxQueryRequest. Makes it easier to distinguish them.

I am open to any choice of the names, but we should specify them as separate technical names in the spec, so everyone uses the same names..

[dslmeinte]

I actually like the difference names for the conceptual, synchronous, request/response XxxQuery and the request-only, asynchronous, implementation-specific XxxQueryRequest. Makes it easier to distinguish them.

I’d like to apply Postel’s Law, and at least be consistent in what we put out. So, if we go for messageKind values different from the technical names, at least be consistent in how they differ, and document that difference.

[enikao]

So we do want to specify the WebSocket binding? I'm perfectly fine to do so, we just decided before to not do it.

Best implicit references for that decision:
Minutes

LionWeb-io/specification#338

[dslmeinte]

So we do want to specify the WebSocket binding? I'm perfectly fine to do so, we just decided before to not do it.

I’m not saying that! I’m fine with the wording in the specification that we don’t specify the WebSocket binding, but at the same time it’d behoove us to at least be consistent in our own implementations.

The JSON Schema we publish as part of the delta protocol spec. is weird in that sense, because when used as-is it obviously prescribes a WebSocket binding.

[enikao]

Shall we say "The 'spec' for WebSocket binding is whatever is inside the JSON schema"?

[dslmeinte]

Shall we say "The 'spec' for WebSocket binding is whatever is inside the JSON schema"?

Right now, there’s no link directly to the JSON Schema file in the delta section, so the status/role of it is anyway vague. We could make that explicit as: ”we’d do it this way”, and probably mention that messageKind equals <technical name>{Request|Response} for queries.