[Standards] XEP-0313: pending 0.7 update review
Ruslan N. Marchenko
me at ruff.mobi
Sat Apr 4 15:14:02 UTC 2020
Am Samstag, den 04.04.2020, 11:47 +0200 schrieb Philipp Hörist:
> Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko <
> me at ruff.mobi>:
> > Thanks, that makes perfect sense to me as in my limited _mere p2p
> > conversation_ use case all those bells and whistles are rather
> > confusing.I don't understand though the need of _flip-page_ element
> > - the reverse _page_ order is achieved by <before> element (as
> > specified here ). Is it to reverse _message_ order
> > (contradicting to section Querying an archive)?
> <before/> gives you the last page in chronological order, there comes
> no use case to mind where this is useful.
> - Either i want to sync up, then i want them in chronological order,
> so i dont use <before/>
> - Or i want to "backscroll" through history, then i want them in
> reversed order which <before/> and <flip-page> now make possible
To me this doesn't make much difference, last page in proper or reverse
order will still require manual re-ordering in the GUI which already
displays some messages. Same for scrolling back (and re-syncing
It does make sense when using large pages on a fresh (or thin) client -
then yes, you simply prepend messages as they go without much concern.
Is it a convenience method just for this use case?
> > * Communicating the archive ID: not sure how to formulate it but
> > something along the lines: if client expects message
> > synchronisation for outgoing messages it MUST add origin-ID to the
> > sent message and store the ID locally for future synchronisation.*
> > Business Rules -> Storage and Retrieval Rules -> User Archives : At
> > a minimum, the server MUST store the <body> elements of a
> > stanza. The server also MUST store origin-id element if that was
> > supplied in outgoing message by archive owner.
> Its not strictly needed that the archive preserves the origin-id, its
> not even needed for deduplication that you use origin-id at all.
> Whatever you put now in origin-id, just put into the standard
> message-id attribute. message-id attribute is already preserved by
Oh, i didn't know that (and didn't implement that of course server-
side). This will do, although again spec needs to explicitly mention
that. To me message id was always client side tracking (receipts and
stuff) which server has nothing to do about.
My point is rather - specification should call out the need for
outgoing message synchronisation and recommend a mechanism for that
which both client and server implementers can rely on.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards