[Standards] xep-0313 missing features

Lazar Otasevic redhotbits at gmail.com
Sun Mar 4 22:01:43 UTC 2018

> > 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

> 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

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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180304/056575e9/attachment.html>

More information about the Standards mailing list