Struct ServerBuilder 

pub struct ServerBuilder { /* private fields */ }

What a server is built with, and served by, see Self::serve.

Implementations

impl ServerBuilder

pub fn new(exe: &str, inst: &str) -> Self

Build a server named exe/inst, after the executable running it and the name of the instance of that executable, which is how it is registered in the database.

pub fn backend(self, backend: Arc<dyn Backend>) -> Self

The backend to serve with, the default one if none is given, see default_backend.

pub fn database(self, database: DatabaseProxy) -> Self

The database to register in, the one of the environment if none is given.

pub fn host(self, host: &str) -> Self

The host to listen at, see BackendServerConfig::host.

pub fn port(self, port: u16) -> Self

The port to listen at, see BackendServerConfig::port.

pub fn local(self, local: bool) -> Self

Enable or disable registration of the this server’s devices into the local registry, which allow [DevProxy] created in this same process to access the the device directly without going through the backend’s wire protocol.

pub fn class<M: Model>(self, def: ClassDef<M>) -> Result<Self>

Define a class in that server, whose devices the database can then list.

pub fn stop_on_signal(self, stop_on_signal: bool) -> Self

Stop the server on the signals the process is asked to terminate with, which is the default: Ctrl-C, and SIGTERM and SIGHUP on Unix, the console being closed on Windows. The server is then stopped as the Kill command of its admin device does, see Server::stop, and the thread waiting on it deletes its devices, see ServerHandle::wait.

There is a single handler of these signals per process, which serving fails to install if the application installed one of its own: this is then disabled, and the application stops the server itself.

pub fn serve(self) -> Result<ServerHandle>

Start serving: the backend is acquired, every class is made from its definition, and the admin device is added and synchronized, which boots the whole server.

This fails if the admin device fails to initialize, which is what a server that cannot reach its database does: it would have nothing to serve.

This blocks, see Self::serve_async for what does not.

pub fn run(self) -> Result<()>

Serve until the server is stopped, by a signal or the Kill command of its admin device, then delete its devices: this is Self::serve then ServerHandle::wait, which is all the main thread of most servers does.

pub async fn run_async(self) -> Result<()>

Serve until the server is stopped, see Self::run.

pub async fn serve_async(self) -> Result<ServerHandle>

Start serving, see Self::serve, resolving once the whole server is booted.

impl ServerBuilder

pub fn from_args() -> Self

Build the server from the command line of this process, see ServerArgs, which is what launching a server usually takes. The process exits with its usage when the command line is invalid or asks for help.

See Self::from_raw_args for what the server is named after.

pub fn from_raw_args(exec: Option<&str>, args: Option<&ServerArgs>) -> Self

Build the server named after that executable and the instance of that command line, see ServerArgs, which is also where it listens. The logs of the process are printed at the level it asks for.

With no executable given, the server is named after the one of this process, as cppTango names it: the name the process was run under, without its directory nor the suffix of the platform’s executables, which is what the Starter of a host runs a server by. Giving one keeps the name of the server whatever its file is called.

With no command line given, the one of this process is parsed, as Self::from_args does; a server with options of its own parses it itself and gives what it flattened, see ServerArgs.