
Just my 2 cents I think that whether this should be reverted or reworked should be between the person raising this issue (Glyph) and the author of the PR (Jonathan). Glyph has asked me to submit the type annotation work on AMP, I will do
On 2020-10-20 04 h 57, adi at roiban.ro (Adi Roiban) wrote: this. I also plan on resubmitting a reworked patch that addresses the issues that glyph raised.
I see that Jonathan has responded to the feedback inside the merged PR.I hope it can be reworked.
Since AMP v2 is not standardized maybe is ok to have it as a separate experimental top level name.
I have never used AMP ...I tried to use it via ampoule but ended up using the stdlib process pool as I was not able see any performance difference.
Since `amp` is used by `trial -j` we need to keep it inside twisted.
But since AMP v2 is experimental, I think that is best to have it as a separate txamp2 project. In this way, the twisted AMP v2 project can follow its own rules. Once AMP v2 is "mature" it can be moved to core twisted
So my take is to revert it and move it to twisted/txamp2.
I have no issue with changing the name or if this patch lives as a project besides twisted. I might even rework it into something more forward-compatible as suggested by glyph. I think netstrings are a decent option as it would make long value handling easier since values would always be contiguous without "continuation markers" interspersed. The main thing I dislike about netstrings are the variable-length ASCII numbers, but that is not a big complexity. Could the next AMP version use values framed using 32 bit or 64 bit integers ? Transmitting long-ish values is a real use case and whatever extension we do must retain the dead-simple, easy to implement nature of the current AMP protocol. I now realise that I somewhat hijacked the "streaming values" bug (2529). IMHO, streaming should be handled at the application level, but I digress.
----
BTW this is also my suggestion for the PR trying to introduce support for SMB.... have twisted SMB implementation in a separate project.
All the best, Jonathan