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

should be converted into #18

Open
arhadthedev opened this issue Oct 26, 2022 · 0 comments
Open

should be converted into #18

arhadthedev opened this issue Oct 26, 2022 · 0 comments

Comments

@arhadthedev
Copy link
Owner

_start_tls_compatible = True - так как это обёртка, убираем подобную логику

self._loop = loop - будет ли работать класс, если указать loop, отличный от текущего?


asyncio: SSLProtocol and _SSLProtocolTransport are heavily coupled so need merging

Analyzing how asyncio internals work, I was puzzled by a role of asyncio.sslproto._SSLProtocolTransport, its domain relation to asyncio.sslproto.SSLProtocol, and why the latter is a thin shell that just redirects all function calls back to SSLProtocol.

After spending some time matching the ends I found out that both classes are actually two faces of the same object. One is the plaintext side looking at user-supplied Protocol, and another is the cyphertext side looking at the actual data source. Thus, they are extremely coupled and cannot be seen independently.

As a result, these two objects need to be turned into two interfaces of a single asyncio.sslproto.SSLProtocol. In other words:

class _SSLProtocolTransport(transports._FlowControlMixin, transports.Transport):
    ...

class SSLProtocol(protocols.BufferedProtocol):
    ...

should be converted into:

class SSLProtocol(protocols.BufferedProtocol, transports._FlowControlMixin, transports.Transport):
    ...

for easier understanding of what's happening and elimination of an excessive entity that requires understanding.

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

1 participant