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

Target architecture and main responsibilities #84

Open
vzurauskas opened this issue May 1, 2019 · 2 comments
Open

Target architecture and main responsibilities #84

vzurauskas opened this issue May 1, 2019 · 2 comments

Comments

@vzurauskas
Copy link
Contributor

To understand the target architecture better, it would be good to have responsibilities of main entities documented somewhere, at least the initial vision.

Trying to understand #74, I read the discussion here (in addition to looking over the current codebase), and this is what I understand from it:

Wire is responsible for maintaining connection over time, which involves:

  • Passing bytes back and forth.
  • Interpreting at least some headers, e.g. Connection and Keep-Alive, and therefore parsing at least a part of the byte stream.
  • Possibly reconnecting if server closes the connection for any reason?

Response is responsible for reading the byte stream and closing the Wire (only if it's the last response in the "Keep-Alive" exchange series?)

Request is responsible for packaging request headers and body, but not sending them to server - Response does that (awkward?) via the Wire.

Is that correct?

What about Wire upgrades? As I understood from here, Wire should be dumb and not be able to upgrade itself, but that discussion happened before the one I mentioned earlier, from which I understood Wire needs to be able to understand at least some headers, so in principle it could also be responsible for upgrading itself? Not sure how good of an idea this is.

In any case, it would be good to have a clear list of responsibilities for Request, Response and Wire, and also a few code snippets of approximate intended usage, similar to here and here (they were quite useful for me in trying to understand all of this).

@0crat
Copy link
Collaborator

0crat commented May 1, 2019

@llorllale/z please, pay attention to this issue

@vzurauskas
Copy link
Contributor Author

@llorllale ping

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

No branches or pull requests

2 participants