| hg-reviewers |
We should document these so consumers have an easier life.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
| Path | Packages | |||
|---|---|---|---|---|
| M | mercurial/wireprotoframing.py (34 lines) |
| This is like ``serverreactor`` but for client-side state. | This is like ``serverreactor`` but for client-side state. | ||||
| Each instance is bound to the lifetime of a connection. For persistent | Each instance is bound to the lifetime of a connection. For persistent | ||||
| connection transports using e.g. TCP sockets and speaking the raw | connection transports using e.g. TCP sockets and speaking the raw | ||||
| framing protocol, there will be a single instance for the lifetime of | framing protocol, there will be a single instance for the lifetime of | ||||
| the TCP socket. For transports where there are multiple discrete | the TCP socket. For transports where there are multiple discrete | ||||
| interactions (say tunneled within in HTTP request), there will be a | interactions (say tunneled within in HTTP request), there will be a | ||||
| separate instance for each distinct interaction. | separate instance for each distinct interaction. | ||||
| Consumers are expected to tell instances when events occur by calling | |||||
| various methods. These methods return a 2-tuple describing any follow-up | |||||
| action(s) to take. The first element is the name of an action to | |||||
| perform. The second is a data structure (usually a dict) specific to | |||||
| that action that contains more information. e.g. if the reactor wants | |||||
| to send frames to the server, the data structure will contain a reference | |||||
| to those frames. | |||||
| Valid actions that consumers can be instructed to take are: | |||||
| noop | |||||
| Indicates no additional action is required. | |||||
| sendframes | |||||
| Indicates that frames should be sent to the server. The ``framegen`` | |||||
| key contains a generator of frames that should be sent. The reactor | |||||
| assumes that all frames in this generator are sent to the server. | |||||
| error | |||||
| Indicates that an error occurred. The ``message`` key contains an | |||||
| error message describing the failure. | |||||
| responsedata | |||||
| Indicates a response to a previously-issued command was received. | |||||
| The ``request`` key contains the ``commandrequest`` instance that | |||||
| represents the request this data is for. | |||||
| The ``data`` key contains the decoded data from the server. | |||||
| ``expectmore`` and ``eos`` evaluate to True when more response data | |||||
| is expected to follow or we're at the end of the response stream, | |||||
| respectively. | |||||
| """ | """ | ||||
| def __init__(self, hasmultiplesend=False, buffersends=True): | def __init__(self, hasmultiplesend=False, buffersends=True): | ||||
| """Create a new instance. | """Create a new instance. | ||||
| ``hasmultiplesend`` indicates whether multiple sends are supported | ``hasmultiplesend`` indicates whether multiple sends are supported | ||||
| by the transport. When True, it is possible to send commands immediately | by the transport. When True, it is possible to send commands immediately | ||||
| instead of buffering until the caller signals an intent to finish a | instead of buffering until the caller signals an intent to finish a | ||||
| send operation. | send operation. | ||||