On Aug 24, 2021, at 12:18 AM, Ian Haywood <ian@haywood.id.au> wrote:

I need to push messages to clients stuck behind a firewall. Existing solutions use polling of various forms. AMP would be perfect but for the 64k field size limit.

The 64k field size limit is a bit of a misnomer. It's a limit on the default types, because you shouldn't be cramming huge values into messages in the default case; every payload should be of finite size. It's not actually a protocol-defined limit. There's no limit on message size, or even field size, really, just individual key/value pair size. You can trivially work around it yourself by defining a "large payload" type, like this: https://bazaar.launchpad.net/~glyph/+junk/amphacks/view/head:/python/amphack... <https://bazaar.launchpad.net/~glyph/+junk/amphacks/view/head:/python/amphack...> Perhaps something like this should be included within Twisted, which is much less of a departure than this "v2" version of amp (which has a lot of interop issues).

There has been a previous attempt to address this (https://github.com/twisted/twisted/pull/1417) however this was reverted with a request to split the PR into the type annotations (presumably uncontroversial) and the protocol changes.

The original contributor has done the type annotations (https://github.com/twisted/twisted/pull/1459) but they seem to be in "review queue hell" Can someone take a look and either merge it or specify what further work needs to be done?'

The best way to get stuff reviewed is to review other things in the queue to keep it as small as possible :).

With regard to the protocol changes there was discussion of using netstrings. Is there any interest in a AMPv2 based on netstrings?

I'd definitely prefer the netstrings version. (And an explicit length-limitation in type signatures rather than depending on this somewhat arbitrary 64k boundary. There should be a finite limit, but it should be application-defined.) -g