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
reduce bifurcation of library internals by using low-level API in high-level API #1723
Comments
I've spent some time thinking about this. Here's my thought process so far. @ctz, @djc does this match your expectations? It seems like I'm imagining that the loop over I think the I think the majority of work would be in adapting WDYT? |
I think my high-level goal would be that Other than this detail, that all sounds good! |
I think one call of Remainder sounds good! |
I think we're on the same page here. Agreed for sure that the buffered/unbuffered part is orthogonal to whether it's a client or server conn.
Ah ok yes, that makes sense and I think resolves some of the uncertainty I had with regards to how to map some of the Thank you both for the input 🙇 |
I'm still struggling to find a way to make the strategy I described above work with the existing buffered and unbuffered API designs. The biggest issue I'm wrangling right now is how to rectify the design of a client like Currently for both APIs the guts of the library put writable tls data into the My idea for how to replace the buffered API with an adapter to the unbuffered API was to have the adapter layer maintain that second outbound TLS buffer, writing to it as dictacted by the The issue I'm seeing with tlsclient-mio is that it doesn't call Is there something obvious I'm missing or is this approach a non-starter? |
Maybe the updated connection common |
How about doing |
Continuing my practice of rubber ducking long comments into this issue.
That was a helpful suggestion, but the same general problem crops up elsewhere. APIs that queue data for the next
|
Is your feature request related to a problem? Please describe.
The gradual introduction of a lower-level API that grants callers more control over allocation has bifurcated the internal structure of Rustls somewhat. This can be problematic with respect to test coverage and maintenance: e.g. most of our existing test coverage is using the higher-level API.
Describe the solution you'd like
We should make a concerted effort to implement the higher-level API on top of the lower-level API, reducing the bifurcation and ensuring that our existing test coverage also applies to the lower level API without needing to duplicate test cases.
The text was updated successfully, but these errors were encountered: