search

gulachek / catui

IPC based application framework
0 stars 0 forks source link

Handshake on server/client protocol versions #10

Open gulachek opened 10 months ago

gulachek commented 10 months ago

Seems important for future compatibility to exchange client/server versions. Client to know server for diagnostics or handling multiple major versions or conditionally using features. Server to know client to only send input messages the client understands

gulachek commented 10 months ago

The problems to solve in this issue before deciding what to do are:

  1. Assume a newer version of spec implements a new output message. Client should be able to use older version server assuming it can avoid sending that output message, but also make use of it when available.
  2. Assume a newer version of spec implements a new input message. Server should not break older version clients by sending an unrecognized message, and should be able to use new feature for newer clients.

For 1, the client can use a catui request to require the minimum feature set it actually needs. The catui ack should include the server version, so if it's newer than the base version that's requested, client can choose to conditionally use newer features. Seems easy and should make new issue on catui.

For 2, server already knows that client is aware of all features available in requested version. But it doesn't have the info to know that it can use newer features.

Semver seems to be designed for 1-way communication. Consumer calls API, but this is 2-way communication. Probably need to communicate 2 versions in that case for catui handshake. Extra communication overhead in catui seems negligible compared to needing every protocol to implement 2-way version scheme management, so this is being moved to catui.