feat: Limit the size of aggregated WebXDC update to 100 KiB (#4825) #5490
Conversation
iequidoo
force-pushed
the
iequidoo/webxdc-update-limit-size
branch
from
d4238cd
to
0df1218
Compare
iequidoo
changed the title
What happens in case of message draft where sender wants to set up everything (e.g. a poll) before sending the message out? I think this should always be a single message so we are sure that second message is not lost. In case of forwarding we don't send updates anyway. |
Makes sense, i'll change this back. But in case of resending it's easier not to send any updates together with the instance, but in separate messages of limited size.
True, and this is not changed, will fix the commit message. EDIT: Done |
iequidoo
force-pushed
the
iequidoo/webxdc-update-limit-size
branch
2 times, most recently
from
8ddb466
to
24baa5c
Compare
Before, update sending might be delayed due to rate limits and later merged into large messages. This is undesirable for apps that want to send large files over WebXDC updates because the message with aggregated update may be too large for actual sending and hit the provider limit or require multiple attempts on a flaky SMTP connection. So, don't aggregate updates if the size of an aggregated update will exceed the limit of 100 KiB. This is a soft limit, so it may be exceeded if a single update is larger and it limits only the update JSON size, so the message with all envelopes still may be larger. Also don't send any updates together with the WebXDC instance when resending it to not complicate the code, the only downside is sending one message more.
iequidoo
force-pushed
the
iequidoo/webxdc-update-limit-size
branch
from
24baa5c
to
7136e48
Compare
See commit messages.
Close #4825