TLS examples should load certs from memory

[0x00002a]

There is a pretty big issue with the tls examples currently: they rely on relative paths to find the correct certs. We could move these into global constexpr string views and load directly from memory to fix this quite easily.

The client-websocket-secure example is broken currently, unless you run it from four directories down relative to the malloy route (the bindir is currently 2 directories down, presumably this is from before we moved everything in bin), and all the other (tls) ones are broken unless run from <malloy root>/*/*.

Ideally we would also load the static content direct from memory, but that might cause issue with demonstrating the file routing.

Yet another alternative could be to bake the absolute paths of the files into the examples via defines, which would be ok I think because they're just examples and not designed to be used on their own, some dependence on malloy files at runtime is ok (just not to the point of dependence on where the binary is invoked from or located lol), but I don't know how useful it would be from a learning perspective to just have a bunch of macros instead of file paths

[Tectu]

We could move these into global constexpr string views and load directly from memory to fix this quite easily.

+1

Ideally we would also load the static content direct from memory, but that might cause issue with demonstrating the file routing.

Yep, exactly.

Yet another alternative could be to bake the absolute paths of the files into the examples via defines, [...]

Wait for it....

[...], but I don't know how useful it would be from a learning perspective to just have a bunch of macros instead of file paths

Exactly my reasoning too!

I'd say lets do this: TLS certs/keys for the example(s) are loaded directly from memory. The remaining parts I'd leave as it is for now to keep the examples as readable as possible. I don't really like that the examples have so much code duplication going on but I really don't want to do that thing where you create infrastructure specific to maintaining examples / lowering code duplication as it makes it harder for someone looking at it to understand "what it takes" to use this library and ideally "how easy it is to use it".

[0x00002a]

I don't really like that the examples have so much code duplication going on but I really don't want to do that thing where you create infrastructure specific to maintaining examples / lowering code duplication as it makes it harder for someone looking at it to understand "what it takes" to use this library and ideally "how easy it is to use it".

Yeah I was originally going to include ideas for tackling this in the issue too, but looking at the examples they are mostly just a few lines of setup and one line of teardown (at least after #102), really quite minimal. I don't really see how we could merge that in a way which was actually shorter while still being flexible enough for all the slight variations in setup needed. One thing I suppose could be moving the base config creation to a function which just took thread count and using that for anything but the basic examples (by which point you're assumed to know how to init malloy already), it would only save a handful of lines but its a least a little less noise. Could also have a function which did the more advanced setup of the server config with default values, and introduce it to the user somehow before we started using it, that would also remove some setup which I think is helpful for the more advanced examples where the focus should be on the new stuff.

Like I said though its already pretty good, especially for most c++ libraries "basic" examples, and most especially for a networking library; serving a file with load balanced across multiple threads and async in <50 lines is damn impressive (its one of the reasons I started using and contributing to malloy, the router and client interfaces are really nice well done :p)

[Tectu]

Thank you - I really appreciate your feedback! As you know there are some rough edges based on the fact that this was initially meant to be a playground but your contributions are excellent - I appreciate that a lot. I actually picked up a few tricks from you which made their way into other software projects by now :p I really hope that this library can get some traction in the (near) future :)

I do agree that we might justify using some setup function(s) for the more advanced examples.

[Tectu]

We'll leave this the way it is for now in order to keep the examples as easy to follow as possible.