> > > > Matthew, > > I really don't understand this argument. Doing a MAM query is exactly > like fetching a list of ids, except that you also get the content as > well. As I mentioned, I see no case in which you would want the ids > and not the content. Even if you get the ids, you will fetch the > content later. >
yes, MAM query is exactly "like" fetching a list of ids combined with content, but thats the problem i have from the start :) getting the ids+content in the same query is a waste in some (many) cases because local archive can have holes in it when network is bad and lots of disconnects happen (for example live messages come before sync is completed and then disconnect happens = next time we receive immediately some live messages and we have holes) even when we dont have a hole, we may trigger a page fetch of 10 messages where infect we need only 2-3, and again we have a waste in my proposal waste would be only some of the ids discarder, so very little. good thing is that ids can come immediately in iq response and client don't need to collect it out of the stream like in MAM now. and more good thing see below... If you already have the content, why would the client ever perform a > query that overlaps with ranges of messages that it already has? Just > none of this makes any sense to me see previous - holes > > 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). > > By back-filling I was less concerned about the direction and more > concerned with showing the user a new message in the conversation > without also showing them the messages before it. That is, showing a > conversation with "holes" in. > any user friendly client should not prevent user to do live communication while the sync is in progress. and there you gave a hole already. conclusion: clients should not focus too much on solving something that is out of their control, and that is holes. BTW viber works from newest message to oldest ones, i have a video of viber on a bad network to prove it. > I totally *do* understand that some clients would like to fill the > message log backwards dynamically as a user scrolls. Querying > backwards from a known id is already possible. > > yes we elaborated that > > 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? > > Can you explain what your ideal client logic would be? And how it is > more simple than "the latest message I have has ID XXXXX, request all > messages since XXXXX"? > yes, i can give you not only ideal logic but also ideal SW design of a client... lets say I make client from 3 components: sender, receiver and sync. goal is to have them decoupled, and the only shared part will be the local message archive here is how the archive is filled: 1. sender - fills archive with message content when outgoing message is confirmed to be sent 2. receiver - fills archive with message content when it receives a live message 3. sync is the only one that takes care of the order, and also filling the holes. order is implicitly given by list of ids received from the server, and holes are easily detected by simple query to archive and then potential holes filled by an extra request (with collection of ids) note how everything can work decoupled, no special handling for sync on connect/disconnect/send/receive, no id tracking, etc... simple and no waste (except a bit of ids), every component can work with/without every other. BTW using request with ids for push purposes is just a special case of that request that we miss. @Philip maybe you find some answers here? ... PS one more thing why MAM direction is important to clients is - receipts, because if client fetches first the message and then the receipt (old to new) then message is in the wrong state (hint: multidevice or reinstall + own messages/receipts) > > Regards, > Matthew > > Regards, Lazar
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
