[Standards] xep-0313 missing features

Lazar Otasevic redhotbits at gmail.com
Sun Mar 4 17:30:39 UTC 2018


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

Please keep in mind multi device scenarios. If one device misses a lot of
messages then back filling "feels" proper way for me - I want new messages
first (live messages also)

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?


Thanks


On Sun, Mar 4, 2018 at 4:36 PM, Matthew Wild <mwild1 at gmail.com> wrote:

> Hi Lazar,
>
> On 3 Mar 2018 22:54, "Lazar Otasevic" <redhotbits at gmail.com> wrote:
> >
> > Hi, I think I miss some features here:
> >
> > 1. fetching messages by giving a set of ids, also similar like xep-013
> >
> > Fetching message by id(s) is needed  for example when i have a custom
> push notification with a given message id(s) and client needs to get that
> one message asap and show it in the chat.
>
> Why not just do a normal query? It feels wrong of a chat UI to show a
> message in a chat and later 'back-fill' the conversation. A message may
> easily be taken out of context this way.
>
> > 2. fetching message ids instead of entire messages, similar like
> "message headers" in xep-013
>
> I don't see why this is helpful. Why would a client want the stanza
> metadata but not the stanza?
>
> > Fetching just message ids is harder to explain why its needed, but I
> think its a must have if one wants to make an efficient and reliable local
> message archive synced with server archive, and to make it as separate
> module independent from the rest of the client. Basically by fetching
> message ids we try to detect "holes" in our local archive and then we fill
> that holes by doing step 1. I think this is a standard way of doing the
> sync algorithm, and its mind boggling why its not here in MAM already.
>
> Similarly I don't see what advantage this brings. Hole detection is
> already possible today with the current protocol, with no overhead of
> additionally fetching IDs and doing an inefficient list comparison.
>
> I really want to keep the XEP as simple as we can, and right now I don't
> see enough justification for adding these features.
>
> Regards,
> Matthew
>
> _______________________________________________
> 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/20180304/42433c64/attachment.html>


More information about the Standards mailing list