You dont need to determine holes, maybe you should first come up with a
scenario where this "hole" of yours can even happen.

1. if you receive a message live you get the archive-id, then you save it.
2. You go offline
3. Once you come later you request after = archive-id
4. repeat

Please show me what can go wrong with this simple approach

So the only thing that would possibly overlap here is a message that you
sent after the last message you received, so in most cases that is 1-2
messages.
Yeah technically a waste but there is no efficient way to get the
archive-id of a sent message, its always going to need another stanza from
the server to tell you.



2018-03-06 13:23 GMT+01:00 Lazar Otasevic <redhotb...@gmail.com>:

> Conclusion:
>
> 1. it is not possible to iterate efficiently backwards by including both
> <before>&<after> in the query because once <after> is included in the query
> then it iterates forwards. that means when iterating backwards client has
> to omit <after> and fetch entire pages and then the last page will mostly
> overlap with some of the local messages, which is a waste.
> 2. it is not possible to determine "holes" in the archive reliably,
> because client can not know what is the last message archive-id, because
> our own sent messages have no feedback from the server once the message is
> archived what is its archive-id ... that means that client has to fetch ALL
> messages from MAM once again just to be sure that holes are filled, even
> though many message-bodies are already received/sent during live
> communication.
>
> Basically In the current state all our own messages are "holes" in the
> local archive, not to mention all kind of "bad network" scenarios,
> multi-device and longer offline periods.
>
> Making separate requests, one for archive ids and one for content would
> make:
> - much less waste in the sync because only ids would be wasted, and not
> the content
> - possible to fill multiple holes in one request by fetching content that
> is really needed
> - make possible for push payloads to contain only message ids (when
> clients want to handle encrypted messages locally by fetching them and only
> them) currently it is doable by giving to the push one id before the wanted
> message
>
> Thanks.
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________
>
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to