[Summit] How-To documents? (was Re: whiteboard notes)

bear bear42 at gmail.com
Tue Nov 6 17:07:48 UTC 2012


On Tue, Nov 6, 2012 at 8:48 AM, Winfried Tilanus <winfried at tilanus.com>wrote:

> 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?
>
>
I think this is a great idea.  While I'm probably one of the last people to
author said documents, I would love to help in any way I can.


> 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)
> >
> >
> >
>
>


-- 
Bear

bear at xmpp.org (email)
bear42 at gmail.com (xmpp, email)
bear at code-bear.com (xmpp, email)
http://code-bear.com/bearlog (weblog)

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/summit/attachments/20121106/b7155f5b/attachment.html>


More information about the Summit mailing list