Tool for generating an inverted Client FSM from a Server FSM

Hey folks!

Yesterday I uploaded a tool for managing Finite State Machines (FSM)
onto https://github.com/willy610/fsm2fsm-main

Boring? NO! Not yet another FSM!
For newbies but also for refreshing existing FSM solutions I think.

Offer a Brand new approach.

  1. From a Server-FSM you can also generate a Client-FSM. They can then collaborate on a session.

  2. Strong new Design Pattern. FSM, MessageFactory, GuardFunctions, MessageProducer, Business Object.

  3. The tool can generate code for Rust and C. Examples in the package. No external dependencies.

  4. Build, debug and run on macOS, Windows, Raspberry Pie. Verified.

  5. One example: An UDP-client in C interacts with an multi-session UDP-server in Rust.

  6. Tool offers several visual views of a FSM.

  7. Lot of Rust code to dig into. Collections, objects, closures, svg-generators, understandable! folder structure for sources etc

And Rust is really strong everywhere. Together with VS Code and debugger for both Rust and C it's a pleasure.

Have a look. The REAMDE is quite huge. Chew to own taste and background

Sounds a lot like session types. Are you aware of them, and if so, how do they relate to your project?

NO, not aware of session types.

But,
browsing around I found that Scribble is
used for specification of protocols.

When writing such a protocol (binary) you must specify both the server and the client
and what they send and receives.

So the mapping from my FSM could be the possibility to
generate the Scribble protocol from just the server FSM, I think.

Hope that did show some connection

I did a quick search on Google to see if there was a nice extant article about it, but alas so here goes:

Essentially the idea of session types is a generalization of the typestate pattern. In the typestate pattern you have a type that is instantiated, and that instance is turned into an instance of a different but related type when some operation is done.
The builder pattern is a special example of this, in that the old and new types are the same.

Session types take that concept and run with it, in that now you have typically 2 instances of complementary types (one client-side, the other server-side) that are necessarily kept in sync because a .send() call turns e.g. the client-side object into a different type (let's say Sent<T>, which only defines a .receive() method). Because of this .send() cannot be called again until the server takes some kind of action (e.g. sending a response). The client then calls e.g. .receive() which turns the client-side object into back into the type that has a .send() method.
A similar process happens server-side.

The detail that makes this work in Rust and not in eg Java or Python is that Rust has a linear type system, which is just a fancy term for saying that the type system can guarantee that an object is used precisely once.

Your project sounds a lot like that to me, except you don't define the types themselves. Does that sound about right?

That sound about rigth.

Just for clarification, I hope:

The source generated in my project is not limited to Rust.
Code is generated for C also if you want to.

The generated code could have been Java, Python or whatver.
And the tool could have been written in other language then Rust.