On 10/26/2012 11:29 PM, bear wrote: (Moving this to standards. Including the summit notes for reference).
Hi, Looking over these notes, I get the impression many issues are already solved with one or more XEPs. But even within our community many of these solutions are not generally known or how these XEPs can interact is not clear. How would that be for a fresh implementer, looking for libraries and standards to quickly build an application? So shouldn't we take some time to write a bunch of How-To documents describing ways to attack common problems. Issues that come to my mind are: - Shared BOSH/websockets c.q. cross-tab and cross-device state sharing - XMPP over unreliable and low bandwidth connections - Setting up a to HTTP/websockets restricted client Probably there are more topics to cover. A good writeup of the discussion at the summit should probably cover the first two topics. Unfortunately I won't be able to do that, though I might be able to pull on the last one. Any opinions / idea's / additions on this? Winfried > Here are the notes I took - any errors or gaps are mine, please > add/correct if you spot them: > > > Thursday, 2012/10/25 > > 1. Informational XEP on acking > 198 - stream management > bosh 124 > message receipts 184 > stanza acking > AMP - 79 (deprecate?) > > how big to keep a queue > which XEP does what? > when to use which tools > > 2. batch size to controllable in BOSH > 3. BOSH cleanup > 4. 198 w/websocket > > BOSH > > 1. BOSH vs WebSocket > 2. XMPP over WebSocket > 3. batch / buffer size > 4. General BOSH cleanup > - pipelining, > - what happens when two requests are received with the same RID > - terminate all sessions when close request is made? > 5. Session attachment > - prebinding > - oauth in HTTP > - SASL XMPP == tunneling > - no channel binding > - 206: header with token > <body> > <sasl/> > </body> > 6. Shared BOSH > - won't need it once we have shared web workers > - do this at BOSH layer of XMPP layer? > - subscribe to existing > - roster versioning? carbons? > > Friday, 2012/10/27 > > Shared BOSH > - client state at application level > messaging carbons > pubsub - sub from all resources > muc - join from all (shared nicks) > - issues: latency > - cache on the server with SAM (Stanza Archiving Mechanism) > - lost state: muc rooms, pub sub, transport registrations, etc > - autojoin > - joined rooms > - store in a roster? > > 1. PEP Versioning > 2. best practices for saving state > > JSON > - object formats > - map e.g. pubsub to S.S.E > (generalize: content-type) > BuddyCloud - API Server > https://buddycloud.org/wiki/Buddycloud_HTTP_API#Content_Types > https://github.com/buddycloud/buddycloud-http-api > - wire format vs objects in code > - socket.io like experience - stanza.io > > Mobile > > bandwidth better, latency = issue > data still costly > always-on xmpp not workable > push notification to wake up > best practices for considering a session to be dead (XEP-198 resumption) > negotiate keepalives > EMN = OMA spec for SMS wakeup > wakeup (with IMAP id to ??? server) > client tells server to use wakeup > don't send me presence (SIFT? or Google Queue-ish) > > >
