On 23 Jan 2017, at 15:38, Georg Lukas <ge...@op-co.de> wrote: > > * XMPP Extensions Editor <edi...@xmpp.org> [2017-01-17 16:24]: >> Abstract: This specification provides a single-request replacement for >> several activities an XMPP client needs to do at startup. > > I know this is a bold request, but as a client developer, I wish for the > following from bind2: > > 1. Client performs authentication (outside of bind2 focus) > > 2. Client sends a bind2 element with the following optional payloads: > - last received MAM-ID, > - last-used-resource > - last SM session-ID + h > > 3. Server performs magic: > > - if the SM session is valid, perform a SM resume, otherwise:
That seems like it might be interesting. > - kill the old server-side session identified by last-used-resource That seems potentially useful. > - bind a new session, using last-used-resource or a uuid > > - enable SM + resumption > > - start sending MAM messages to the client starting after last received MAM-ID This one I’m not convinced by. You’re going to need to deal with multiple roundtrips for doing a full MAM sync on login anyway, because the server likely won’t return all results in a single query, and I’m not sold that doing a full sync before the client is responsive is necessarily sensible. > This approach would have multiple benefits: > > * Less roundtrips (when <resume> would fail; for MAM response) The MAM response doesn’t actually need to be a roundtrip for the first results, even without this, because you can issue a query in the same write. > * Smarter server, dumber client (original XMPP design goal) > > * One-step creation/restore of a properly configured session Merging resumption seems potentially useful, yes. > Regarding the random vs. client-supplied resource, I'm strongly in favor > of having the client generate a random resource like "yaxim.DEADBEAF" on > first use. This makes debugging problems easier for server operators, > and I can say from experience that running a server is hard enough > already. Being able to tie a unique identifier to a client for server debugging is useful, but I don’t think it’s the job of the resource to encode it. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
