Fallibility of starting a trillium server

[quixoticaxis]

Hello.

The question arose while I was trying to implement a toy book library utility that provides an optional web interface. The runner's run method does not return Result<()>, so the inability to bind to the address becomes a hard error. Is it intended or a work-in-progress API limitation?

[jbr]

One aspect of trillium's modularity is that components like the runtime adapters are intended to be modular as well. The current runtime adapters are primarily intended for ease of use for running servers where if they cannot bind to the specified host/port, the process should exit. It would not be difficult to either extend the current adapters to support fallible server starting, or build a new adapter that supports that special use case. A goal for trillium is to have a specific production use case in mind when making changes to an interface that impacts all users. What would you want to happen if you couldn't bind to the specified host and port?

[quixoticaxis]

In the situation where it's an optional server, why wouldn't you want the user to specify that? If you're looking to use a random but available port, you can use something like portpicker

I assume that asking the user for the port is fine if the end product is a technical utility. If it's a product targeted at not IT audience, I suppose, it is no longer viable.

[jbr]

I believe any infrastructure service distributed as a single executable would do, I suppose. Off the top of my head I can imagine a few:

A service that handles live back-ups of the disks and may run an optional simple HTTP server to serve statistics.
A database that can optionally host it's own monitoring portal.

I would have expected these to accept command line configuration for the host and port (or to enable/disable the server). Alternatively, if you don't specify a port/host for trillium, it will pick up HOST and PORT from the environment.

I think a good escape hatch that wouldn't make people write run(…).unwrap() everywhere would be accepting an already-bound TcpListener instead of a host and port. I'll take a look at adding this to Config!

[jbr]

I assume that asking the user for the port is fine if the end product is a technical utility. If it's a product targeted at not IT audience, I suppose, it is no longer viable.

How does the user know how to visit this url if they haven't specified the port themselves? Does the CLI open a browser? This was the sort of thing that I couldn't figure out when I built out tide's listener api (which is fallible, but all of the examples just unwrap the call that starts the server)

[quixoticaxis]

How does the user know how to visit this url if they haven't specified the port themselves? Does the CLI open a browser? This was the sort of thing that I couldn't figure out when I built out tide's listener api (which is fallible, but all of the examples just unwrap the call that starts the server)

Yep, the utility can always feed the url to the OS, which would open the default browser.

[quixoticaxis]

I think a good escape hatch that wouldn't make people write run(…).unwrap() everywhere would be accepting an already-bound TcpListener instead of a host and port. I'll take a look at adding this to Config!

That would be great, and would leave an option of a zero-cost update if std::net::TcpListener is ever extended with additional capabilities.