[Standards] xep-0313 missing features

Lazar Otasevic redhotbits at gmail.com
Mon Mar 5 11:10:14 UTC 2018


Hi Kevin,

I guess all of your questions are self explanatory, no need for answer,
because client can fit to MAM logic, but I would ask you to clarify just
this one:

> 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 didn't yet get it clear how to specify direction when requesting with
both <before> and <after>?
I guess its doable, but one small detail is how can client be sure of the
correct MAM order in certain race conditions (latest sent message VS latest
received message) without using dates?

BTW Making things layered (id skeleton + content) is not the same as making
them "more complicated" its just making them more flexible, but ok,
irrelevant. I repeat MAM removed something that we already had before. Just
for my push example, when client receives only the ids in the payload -
then I have to provide entire message inside the payload? Because client
can not get a specific message(s) on demand by using id(s)... I guess
clients have to live with that.

Thanks for support.



On Mon, Mar 5, 2018 at 10:45 AM, Kevin Smith <kevin.smith at isode.com> wrote:

> 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.
>
> /K
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180305/ab951013/attachment.html>


More information about the Standards mailing list