[Twisted-Python] revert / rework of "AMPv2" change?

[Jonathan Bastien-Filiatrault]

On 2020-10-20 04 h 57, adi at roiban.ro (Adi Roiban) wrote:
> 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
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