[Standards] xep-0313 missing features

Matthew Wild mwild1 at gmail.com
Sun Mar 4 19:32:50 UTC 2018

On 4 March 2018 at 17:30, Lazar Otasevic <redhotbits at gmail.com> wrote:
> 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 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.

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.

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

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.

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


More information about the Standards mailing list