Hi, Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko <[email protected] >:
> > 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 [1]). 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 > * 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 servers. I think the use for origin-id was historically because not all MUC implementations did preserve the message-id or were allowed to rewrite it. But this has been fixed in 0045 since then if im not wrong Regards Philipp
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
