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 <[email protected]>: > 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: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
