[Standards] xep-0313 missing features

Kevin Smith kevin.smith at isode.com
Mon Mar 5 09:45:20 UTC 2018

On 4 Mar 2018, at 22:01, Lazar Otasevic <redhotbits at gmail.com> wrote:
>> 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)

Is there ever a situation where you want the id but don’t want the message? I can’t see why that would be the case - you don’t for hole filling, or recent sync. If you always want the body of all the messages you’re querying then doing multiple queries is unnecessary effort for both the client and server.

> 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 the case that there’s no hole, why would you ask for more messages than you need?

> in my proposal waste would be only some of the ids discarder, so very little.

Yet with MAM you already can do it with no waste, so I’m not sure what this is buying.

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

They still need to do the latter for the subsequent content query, so I don’t see why this is an improvement.

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

You can already fill holes with the current spec, by specifying both <before/> and <after/> on the RSM query can’t you? If that doesn’t obviously follow from the text, that’s something we should clarify.

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

You’re removing a small bit of work for the client (keep track of holes when they happen, which is straightforward enough) and replacing it with a complicated sync protocol that isn’t needed. You keep alluding to the ability to just ‘get all the IDs’ and then request the messages you don’t have, but that’s obviously not possible in one pass, and you’re going to end up needing to do something (merkle tree?) that’s involving several round trips and a more complicated implementation for both client and server.


More information about the Standards mailing list