[Standards] XEP-0313: pending 0.7 update review
mwild1 at gmail.com
Sat Apr 4 13:38:30 UTC 2020
Hi, thanks for the feedback!
On Sat, 4 Apr 2020 at 14:15, Ruslan N. Marchenko <me at ruff.mobi> wrote:
> 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 archive).
> 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?
Pretty much, yes. There is almost no difference to just receiving the
results and flipping them on the client side. However a handful of
client/library developers have asked for server-side flipping instead. I
don't see it as a necessary feature at all, but I do see that it makes some
use-cases a little nicer. For example if you are doing the "infinite
scroll" approach and the user scrolls up, it means you can start displaying
messages in a natural order as they arrive - which may make a perceivable
difference on poor connections.
> * 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.
> 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.
Good call. This is meant to be covered by "The message stanza itself." in
the list in section 3, but I agree it could be made explicit.
> 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.
This was the original intention - the XEP was to include a section covering
the ideal use of the protocol for synchronization. However there are too
many gaps right now (such as this one, and the race at login time). Neither
can be solved without additional protocol work, and I don't believe that
additional protocol belongs here, which just documents a way to query the
archive. E.g. fixing the race at login potentially requires a whole new way
to log in (XEP-0386 is a candidate, for example).
Ultimately I think the simplest thing we need is something that allows you
to bind a resource, enable Carbons(*), and find the ID of the last message
in the archive. All in one operation. (*) Also the Carbons thing should
reflect your outgoing message ids to you (various strategies have been
discussed for that, I'm not sure that any have been written down or
implemented). Also this overlaps significantly with XEP-0409, which I think
describes a sensible alternative to all this - and which received lots of
discussion at the summit a few months ago, but no clear consensus that I
recall (many people don't think it's worth it, as I understand).
Either way, I would like some kind of "How to use MAM" document to exist in
the future, once we figure out problems like this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards