Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renaming controller_run_result #107

Open
Tectu opened this issue Jan 16, 2022 · 9 comments
Open

Renaming controller_run_result #107

Tectu opened this issue Jan 16, 2022 · 9 comments
Labels
discussion General discussions

Comments

@Tectu
Copy link
Owner

Tectu commented Jan 16, 2022

I'm really not happy with the naming scheme used by the newly introduced controller_run_result. It doesn't really reflect the design of the system appropriately in my opinion.

I'd propose renaming controller_run_result to just controller and renaming the current controller class to controller_factory.

@0x00002a Thoughts?

@0x00002a
Copy link
Contributor

For future readers, see my comment in #106 for my thoughts on how we could do this with a session object.

I think there is an interesting issue around how we deal with client controllers. It makes sense for the server one to be a factory if it sets up the routes and they're static one its starts, but the client controller needs to be able to dynamically make new requests. What we could do is have the controller factory and the session both expose the same api for making requests, but then we have to write the same api twice and maintain both versions, unless we want to inherit from some base which I am conflicted about since imo it is an abuse of inheritance but it is also used in stuff like beast (message inherits from header for example) and would let us provide that factory version on the client side while preserving the dynamic stuff

@0x00002a
Copy link
Contributor

I've been thinking a bit more on this, and I came up with another option: make the client api start the runner on construction. For example, make the start function take a config struct directly and have it return the session (or just have the session constructor take it, but the wrapper lets us have symmetry between the server and client). This is somewhat intuitive with the rest of the usage, rather than being something which can be both setup and dynamically used it becomes something which is always dynamically used. We would of course need some way to init tls, for example an overload which takes a tls config struct or something.

To avoid duplication across the client and server, we could use template-based dependency injection to abstract the provider of the io context and thread spawning, this would have the added bonus of letting users specify their own way to run the io context and have direct access to it (although how this interacts with the work guard is something that still needs thinking about imo)

Whether we go this second route or not, I think we need to very carefully consider if we want to allow both the setup and run behavior and the run then setup usage.

@Tectu
Copy link
Owner Author

Tectu commented Jan 19, 2022

I like your approach.
To be perfectly transparent here: I found ZERO amount of time the last three days to look into this properly/decently. It's a constant itch at the back of my head tho... It literally keeps me awake at night.

@0x00002a are you able to spin up a draft for this?

@0x00002a
Copy link
Contributor

0x00002a commented Jan 23, 2022

@0x00002a are you able to spin up a draft for this?

I'll take a crack at it today, probably won't get very far but should at least get more of an idea of the issues

@0x00002a
Copy link
Contributor

I've got through a bit of this proof of concept, but I am feeling a little afraid I'm making such a massive change, my implementation has removed the server controller and made start take a router as the first arg instead (with an optional tls context arg). I've renamed client::controller to client::session and made it start up on construction. I just ain't sure these changes are really justified or even a good idea.

Maybe it would be better to just rename them, I'm worried I'm making substantual changes which arn't needed :p. Any thoughts?

@Tectu
Copy link
Owner Author

Tectu commented Jan 28, 2022

Maybe it would be better to just rename them

That's definitely what I had on mind from the beginning :p
Personally, I think what we have in terms of structure is quite reasonable. What bugs me is mainly the naming of the classes/structs/types that we're using in the current design.
I think that the current structure/design is pretty reasonable and - while maybe not the most minimalistic/elegant solution - I'd argue that it's also sufficiently future proof.

@0x00002a
Copy link
Contributor

@Tectu How about keeping controller named the same, but changing the type alias they expose to be named session. On the client side this makes sense imo, as the controller can keep being used after started but I agree on the server it is less intuitive. session_factory or controller_factory are both a bit unhelpful though imo, I quite like something along the lines of routing_context but its a little verbose :p.

@Tectu
Copy link
Owner Author

Tectu commented Jan 29, 2022

@0x00002a that sounds reasonable. I wouldn't even mind routing_context. I'm also okay with calling the type returned by the server controller::start() just session so it's consistent with the client. After all, it's like a serving session.

Tectu added a commit that referenced this issue Jan 30, 2022
Related to #106 and #107.

* feat: make controller_run_result movable

* chore: improve tests slightly

* fix: accidental removal of m_workguard from controller_run_result

This actually was informative because it showed how m_workguard actually
does matter. See if there is no work guard, and the user calls
run() on a _client_ controller, then enough time elapses so that
all work is complete and there is a pause before new work is added,
the io_context::run() will return for each of the threads, meaning that
in actual fact queuing more actions via the controller (which is valid
after calling start) would not actually do anything.

tl;dr nasty obscure bug, keep the workguard its needed for clients

* feat: add start_result alias to controllers

* coding style

* chore: start_result -> session

* chore: server::controller -> server::routing_context

* chore: server/controller -> server/routing_context

* fix: tests include

* fix: more rename fixes

* fix: session test

* fix example server/applications/demo01

Co-authored-by: Joel Bodenmann <jbo@insane.engineer>
@Tectu
Copy link
Owner Author

Tectu commented Feb 2, 2022

@0x00002a I've been thinking about this (again): Why not just renaming routing_context to context? Then we'd have malloy::server::context which seems pretty intuitively. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion General discussions
Projects
None yet
Development

No branches or pull requests

2 participants