You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The design of hyper is similar enough that we ideally can just use it as is. And in a way that has been done so far. However akin to Tower and friends it also became clear that some of our goals and scope is sufficiently different that there will always be a kind of friction or trade off.
We developed most of rama 0.2 with hyper. In prototypes it became clear that a fork is needed for certain preservation goals. At that point even better is to just embed it directly into the codebase.
We can keep track in our FORK document what commit we are in sync with so that we can keep the codebases in sync.
This ticket is mostly about the embedding work and the use of it. We can already adapt code and drop code where we see it fit. But extensive modifications in the name of traffic preservation and control is best to be left for later tickets, to keep the scope of this ticket somewhat manageable.
The text was updated successfully, but these errors were encountered:
From hyper-util we only use TokioIo and Auto Connection. So those can be directly copied in without copying the client.
We can move all this code under rama::http::core. While doing so we can already remove code we do not need, and make things simpler by knowing we can just hardcode a direct connection to tokio.
However as to not distract from the current priority of getting the high level API, flow and design correct. And while this might impact our code around the http client / server and also things like http upgrades, that is ok. For now let's hold this of until we are ready with the other ongoing tasks which are more important as they are all highly impactful about the design direction of rama and reaching our goals. Embedding hyper as rama::http::core is more a cherry on the cake detail.
The design of hyper is similar enough that we ideally can just use it as is. And in a way that has been done so far. However akin to Tower and friends it also became clear that some of our goals and scope is sufficiently different that there will always be a kind of friction or trade off.
We developed most of rama 0.2 with hyper. In prototypes it became clear that a fork is needed for certain preservation goals. At that point even better is to just embed it directly into the codebase.
We can keep track in our FORK document what commit we are in sync with so that we can keep the codebases in sync.
This ticket is mostly about the embedding work and the use of it. We can already adapt code and drop code where we see it fit. But extensive modifications in the name of traffic preservation and control is best to be left for later tickets, to keep the scope of this ticket somewhat manageable.
The text was updated successfully, but these errors were encountered: