Add support for MULTIAPPEND #2710
Conversation
|
As far as I can tell we never call |
|
I added this to improve PR #2697 . |
|
I see. Makes sense. But it probably needs some additional logic to create sensible batches (e.g. don't try to send 100 MB in one transaction). Another issue is that pending actions are persisted. You can't change the format without migrating existing pending actions stored in the database. |
rhari991
force-pushed
the
support-multiappend
branch
from
78d6623 to
f39fd1a
Compare
|
@cketti I'm not sure what a reasonable limit would be, I've set it to 10MB for now. |
| /* | ||
| * We need uidMap to be null if new UIDs are not available to maintain consistency | ||
| * with the behavior of other similar methods (copyMessages, moveMessages) which | ||
| * return null. |
There was a problem hiding this comment.
We should really change this. Returning null is bad and an empty map would suffice.
There was a problem hiding this comment.
I'd leave this for another PR, since this touches other methods besides append
|
Regarding size limits, we could add support for https://tools.ietf.org/html/rfc7889 Although even with that we would want a sensible maximum. |
|
that's most likely not worth it, since it doesn't seem to be supported by a single server implementation: https://web.archive.org/web/20170315000338/https://imapwiki.org/Specs (unfortunately, the imapwiki.org website is down. I hope this is only a temporary issue...) |
|
Huh that's a really useful link :) |
|
Gmail seems to support it though |
|
Oh, interesting. What's the limit they give? |
|
35651584 |
|
so 34MB. I wonder what a sane limit would be for us to set? 34M sounds like a lot |
Also available in the actual internet ;) |
As specified in RFC 3502