Hi Simon,
On 8/20/21 10:39 AM, Simon Riggs wrote:
Yeah, but it is a change to the protocol which means that the client
drivers and middleware ecosystem needs to be updated to support that
message.
No, because FE messages don't need to be handled by the client, they
just send them.
Yes, but the middleware need to parse them in order to send a response.
It is the server that needs to be updated to
understand that these messages might be received and to ignore them,
which is simple enough.
If a client doesn't know about a message it COULD send, but doesn't,
then there is no update required.
Agreed.
So, if the message was added to the protocol we could add another
message with the response to the request and make the protocol stricter, say
FE/M
Int32 - Length
Int16 - Request type (0 == Query capability, 1 == Execute capability)
Int32 - Capability type (0 == Failover, 1 == ..., ...)
This much detail is optional. It is up to the middleware to define if
it supports capability requests, or how it handles requests that it
cannot satisfy.
I'm trying to come up with something generic that people can use for
decades to come, not restrict their choices to a very small subset
based upon our current vision.
BE/?
Int32 - Length
Int32 - Capability type
Byte - Support (0 == No, 1 == Yes)
Byten - Additional information
If we add a new message from BE, then yes, we need to modify all
drivers, which would be an immediate fail for this proposal.
The message replies you foresee are optional; they are not required by
all middleware.
I've already suggested you use NoticeResponse, which is already
defined to ignore unknown field types, so is suitable and extensible.
We could add a new field type of 'm' to represent a message sent from
middleware to the client.
When doing the PoC just keep in mind that middleware acting on a 'M'
message on a user authenticated connection could lead to a DoS attack.
Best regards,
Jesper
