On 03.11.2017 21:35, Kevin Smith wrote: >> On 27 Oct 2017, at 12:19, Florian Schmaus <f...@geekplace.eu> wrote: >> On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote: >>> This message constitutes notice of a Last Call for comments on >>> XEP-0313. >>> >>> Abstract: >>> This document defines a protocol to query and control an archive of >>> messages stored on a server. >>> 2. Does the specification solve the problem stated in the introduction >>> and requirements? >> >> I guess so, but archiving shouldn't be considered in isolation. A prime >> example is the "archive catch-up on reconnection" problem, for which we >> have some ideas for solutions (MamSub, …). but no champion yet. > > Archive catch-up on reconnection we *can* do with MAM, although there are > other parts that still need solving (particularly unread sync).
I am maybe wrong, since it is been a while that I dealt with the situation, but wasn't there a mechanism missing allowing you to say "Send me all archive messages after X *and* start sending the live messages" (sometimes refereed to as MamSub)? >>> 5. Is the specification accurate and clearly written? >> >> For most parts yes. But it was recently discovered that it is unclear at >> best how MAM+PubSub should work together. It was even pointed out that >> it may be even impossible to use MAM with PubSub, since MAM-IDs are not >> PubSub Item IDs. > > I’m not sure why that makes it impossible. These need to be independent ids, > for the obvious id-in-pubsub-reuse reasons, but I don’t immediately see why > that breaks anything. Imagine the following situation: A client subscribed to a PubSub node wants to catch-up on reconnection. He knows the last item he received a notification for. How does he request all newer items from the PubSub node using MAM? From the current state of XEP-0313, I'm unable to construct an example protocol flow from the last item notification to the full MAM request-response sequence. Maybe the only thing missing in order solve this is a (optional) 'start-pubsub-item-id' MAM form field specification? I note that this situation is the same as the catch-up message archive situation mentioned above. We possibly should have bullet-proof solutions for this before we advance MAM. I am also not sure if I would say that it is obvious that MAM IDs must be independent from PubSub node IDs. It is clear if you think about it, but for an average XMPP developer like me it would probably be helpful to state that explicitly in the XEP. Related comment: XEP-0313 says that the 'with' form field MUST be supported by servers. What is the semantic of the 'with' field when used with PubSub services? Or isn't it a requirement when using with PubSub? Thinking more about it, I would also suggest refactoring the MAM-PubSub part into an extra XEP, which nicely lists and explains the particularities. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
