Matthew, I may be repeating: every efficient sync algorithm needs iterating trough ids and content separately. Of course we may make sync work without iterating trough ids, but implementations like that are just terrible, too complex, too coupled with the rest of design and not optimal.
I agree "back filling" feels wrong for someone and feels right for someone else so its not an argument for technical discussion. Anyhow, direction of iteration should be a client choice (server needs to provide both directions possible). Please keep in mind multi device scenarios. If one device misses a lot of messages then back filling "feels" proper way for me - I want new messages first (live messages also) I thought the goal of XMPP is to make clients less complex and more reliable? Why is adding two (basic) features counted as increasing complexity? I say basic because those features were kind of existent back in 2005 in xep-0013. Now we removed those features, why? Thanks On Sun, Mar 4, 2018 at 4:36 PM, Matthew Wild <mwi...@gmail.com> wrote: > Hi Lazar, > > On 3 Mar 2018 22:54, "Lazar Otasevic" <redhotb...@gmail.com> wrote: > > > > Hi, I think I miss some features here: > > > > 1. fetching messages by giving a set of ids, also similar like xep-013 > > > > Fetching message by id(s) is needed for example when i have a custom > push notification with a given message id(s) and client needs to get that > one message asap and show it in the chat. > > Why not just do a normal query? It feels wrong of a chat UI to show a > message in a chat and later 'back-fill' the conversation. A message may > easily be taken out of context this way. > > > 2. fetching message ids instead of entire messages, similar like > "message headers" in xep-013 > > I don't see why this is helpful. Why would a client want the stanza > metadata but not the stanza? > > > Fetching just message ids is harder to explain why its needed, but I > think its a must have if one wants to make an efficient and reliable local > message archive synced with server archive, and to make it as separate > module independent from the rest of the client. Basically by fetching > message ids we try to detect "holes" in our local archive and then we fill > that holes by doing step 1. I think this is a standard way of doing the > sync algorithm, and its mind boggling why its not here in MAM already. > > Similarly I don't see what advantage this brings. Hole detection is > already possible today with the current protocol, with no overhead of > additionally fetching IDs and doing an inefficient list comparison. > > I really want to keep the XEP as simple as we can, and right now I don't > see enough justification for adding these features. > > Regards, > Matthew > > _______________________________________________ > 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 _______________________________________________
