Remove "server" feature(s)

[uklotzde]

The server features should be split off into a separate crate before releasing version 1.0. This might require to extract shared code into a separate crate.

[cdbennett]

I am actively investigating using this library in projects as both a client and a server.

I agree that extracting the TCP server stuff into a separate crate would be cleaner. I would be interested in perhaps writing some examples/documentation or other ways of contributing to help the project.

[flosse]

This might require to extract shared code into a separate crate.

how about tokio-modbus-server?

[flosse]

... or probably we even create a new "namespace" and split it like this:

• core: nostd compatible like modbus-core
• tokio: general foundation for tokio based usage
• client: convenient implementations & utilities for clients
• server: convenient implementations & utilities for servers

[cdbennett]

When trying to implement a server library, it seems it would be useful to describe some concrete use cases for the server.

This would direct the design of the API and consequently the implementation of the server as well.

Kind of like in test-driven development, or having a real user as a customer, some simple example applications would both help direct the development of an API, and also would give library users an example of how to use the library.

Some things I'm thinking about:

• What kind of applications are people going to use the Modbus server library for?
• How will users handle concurrent requests from multiple clients?

[lindblandro]

Are you discussing splitting the current crate into multiple smaller ones in the existing repository or create multiple smaller repos, one for each crate?

[Halkcyon]

I find the server feature helpful for integration testing, personally, which is how I put it to use.

[cdbennett]

I find the server feature helpful for integration testing, personally, which is how I put it to use.

Agreed, it is useful in many contexts. I think the change is to create a new tokio-modbus-server crate, which uses the core tokio-modbus crate but adds the server-specific stuff.

It makes more sense than shoving into a single crate with a feature flag... the server itself might evolve at a different pace from the core Modbus functionality that a client would need, so decoupling them makes sense.