gthomas · October 25, 2012 20:05 · gthomas · Oct 25, 2012
diff --git a/RTConfNotes.txt b/RTConfNotes.txt
 ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
 ;; If you want to create a file, visit that file with C-x C-f,
 ;; then enter the text in that file's own buffer.

 disqus used
 thoonk, gevent and nginx_http_push to make disqus more "realtime"
 https://github.com/NorthIsUp/disqus-realtime-presentation
 https://ep2012.europython.eu/conference/talks/making-disqus-realtime
 -----

 dotcloud has cool tools
 zerorpc
 js.dotcloud.com
 stack.io
 -----

 social web is the realtime web
 social doesn't work when you have to wait 10 minutes for a response
 superfeedr is a tool for managing feeds
 1. social is b0rked
 - you must choose between friends and services
 - you like path, all your friends are on Facebook etc...
 - we do a lot of stuff, but it's all separated
 - you can cross-post but it gives you lots of dupes (annoying)
 - we will outlive Facebook (also others)
  -- they'll lose our data
  -- we won't be able to recover it when they do
  -- they want to be your identity/auth
 - people choose friends over apps (features/design)
 - people choose devices over apps too
  -- mobile OS are gatekeepers
  
 2. silos won
 - services want to be your one and only web inbox
 - auth via FB etc makes websites suck
 - API as shackles
 3. save the cheerleader (regain what we've lost)
 - fork the web!
 - you can use your browser to change the web (but not permanently)
 - unless you use an extension (run my script always)
 - go ahead and add side-effects that do things on your behalf (add new handlers)
 - browsers can store your data too (localstorage, Locker, Unhosted)
 - put stuff in indexed db in Chrome 
 - you can use tcp to access stuff stored in a browser (Websockets)
 - decentralizes the social web, establish a protocol for social web with data stored on individual clients (a'la dvcs)
 - presence is baked into this model 

 https://github.com/julien51/indie-butler-app

 -----------------------

 The Bilingual Browser
 "a delusion offered for sharing"

 Statement: I think web browsers should talk xmpp and http natively.
 XMPP for web inbox, auth etc
 XMPP solves long-polling etc.. that aren't natural for HTTP.
 HTTP only is piss-poor for that stuff.

 Allows for:
 Presence
 Micro-content push
 -- knows identity of browser and who to push to
 True shared identity
 -- all identity data is accessible through xmpp
 Pubsub

 ----------------------

 SPDY
 - The Past
 http 1.0 in 1996, then 1.1
 built for a different web. tiny 60K pages.
 today, a lot more, richer content. composed of many resources of many kinds
 from many sources.  HTTP has not evolved to suit this.

 Round trip time is the thing. There are around 84 requests per page.
 Stakes are higher, and RTT means money.

 SPDY is a session-lay replacement for HTTP allows multiplexing of connections.
 Goals:
 - Faster
 - More Secure
 - long-term: less effort
 - but: no guarantees

 Header compression:
 - headers are compressed
 - reduces bandwidth
 - 10-25% size reduction for first request
 - 80-97% for longer lived connections
 - Esp. useful in client to server direction

 Pipelining
 - Requests can be prioritized
 - Use all bandwidth all the time
 - Currently browsers manage delay of requesting resources
 - pauses loading/rendering while loading resources
 - bandwidth pipe is underutilized
 - without this, resource contention occurs and rendering is impossible
 - one big burst vs. staggered load
 - SPDY doesn't need this
 - can tell you which resources are high-priority
 - browser can forget about request heuristics
 - uses interleaving to allow "simulataneous" delivery
 - high-priority data can "interrupt" low-priority
 - Solves hacks
 - file concatenation
 - spriting images
 - domain sharding
 - all unecessary with prioritized multiplexing

 Server push
 - already here, called inlining
 -- prevents caching
 -- interferes with prioritization
 - SPDY server push is better inlining
 -- Pushed resources can be cacheed
 -- Also can be cancelled
 -- we don't need to wait for roundtrip
 -- server push can send the "most important" parts first
 -- just have to put the files in order in server config
 - Enables "Silk" and the like to work faster
 - you can set a response header that will allow SPDY for browsers that support it

 ------------------
 Removing the suck from websockets so they're better for the enterprise

 websocket protocol is pretty old (since 2009)
 final in December 2011

 Support in many browsers ie10+ (no Android browser)
 Latest (RFC) in Chrome 20, FF 12, Safari 6, IE 10+, Chrome for Android

 Known issues with Websockets
 - Usage or detecting proxy can crash the browser in older Safari and Mobile Webkit
 -- Have to do browser sniffing to get past this
 - Writing to a closed websocket will crash safari mobile
 -- use setTimeout (even very small) and socket state will be set correctly
 -- (mobile only)
 - 3g doesn't always work with WebSocket, or causes crashes
 -- sniff for mobile
 -- don't use websockets then
 - Pressing esc in Firefox will drop the connection, even if the page is loaded
 -- bug has been open for 4 years
 -- e.preventDefault for "ESC"
 - invalid UTF-8 can drop the connection (even emojis)
 -- unescape(encodeURIComponent(terribleEmojis))
 - Firefox won't connect to non-secure ws:// from https
 - Similar is Safari with self-signed
 -- annoying!

 There are all sorts of edge-cases with websockets

 firewalls, and enterprise proxies block :4000
 most block anything other than 80, 443, 843
 use those ports, or use flash sockets

 virus scanners
 out-of-date scanners will block websocket connections
 depends on the scanner, some block on non-80 ports, some just block everything
 blue-coat proxy blocks all js with "active-x" in source

 in the end, about 10% of websocket requests fail

 reccos
 -------
 Always use SSL for websockets
 Have fallbacks
 - polling 
 - flash
 - etc..
 - order them correctly, "upgrade" to websockets
 Don't use websockets on mobile
 - just poll you dingus!
 Educate!
 - check out realtimeplatform.org
 - sharing is caring


 ---------------------------------

 Firebase (@Firebase)
 "Do you have data? Does it change?"

 - we've got a shitload of awesome tools
 - think bigger than input/output
 - no longer constrained by hardware you can afford

 Firebase is a tool for building full-stack realtime apps without writing 
 any server-side code. HTML5, JS.  It's a full-on backend and datastore for your app.

 1. real-time synchronization
 2. persisten & reliable
 3. scales with your data
 4. data is accessible
  -- in "cloud" via unique URL
  -- in code
  -- in browser
  -- as REST endpoint

 -----------------------------------------

 WebRTC is almost here -- CTO from Voxeo/Tropo (Jose de Castro)

 WebRTC is a new API for embedding real-time communications into web sites and 
 browser-based applications
 Access to camera and microphone
 P2P camera, microphone, real-time media streaming.
 Interoperable codecs, very secure (GVM'T grade encryption), part of w3c 
 standards and a native part of the browser.

 What's possible
 Voice and video chat
 specialized chat networks
 real-time gaming data
 integration with regular phones
 live events, journalism
 next-gen contact center

 Communications Value Chain
 - Access
 - Identity/Addressing
 - Services
 - Presentation

 Voxeo focuses on Services and Presentation
 WebRTC is not forcing a UI on us. There is no phone, but you can make a call.

 How does it all work?
 2 peers need to exchange some info
 - which codecs do they support?
 - what's their IP

 You'll need to manage this in your application
 - receive the request from each peer
 - pass the infomation to peers
 - negotiate the connection between peers
 - use SIP, Jingle (XMPP) or your own protocol
 - your site (or Facebook) can pass the connection blob through their own methods

 Not just video chat, any live content can be pushed in real time from peer to peer.
 Big shit-fight over video codecs (webm (royalty-free) vs. h.264 (patents, $$$, not GNU friendly))

 check out
 <video><audio>
 GetUserMedia
 PeerConnection API
 DataChannel API

 RTP/SRTP
 SDP
 ICE/TURN
 Opus Codec
 DTLS

 Try it out in Chrome 24, IE, Firefox soon, Safari follows
 Watch out for boot2Gecko (Firefox OS, HTML5 + JS atop Android kernel)
 Maybe even Android by next summer

 Evolving standard get involved.
 Try out phono, built frame upon webrtc that falls back to other things (Java, Flash etc..)

 ------------------------------------------
 Realtime is not just for the web.

 Telephony.
 Mobile handsets are ubiquitous world-wide where home computers are not.
 In the dark ages we had proprietary islands of functionality to run
 phone networks. No API.

 VOIP is a reaction to this. Frees us from big expensive boxes.
 Also nicer clients help too (iPhone, software etc)

 Convergence and the beginning of unified communications. 
 WebRTC and open architecture are encouraging democratization of communication platforms.
 Federation, Multi-modal integration (voice + video + text + presence all at once in one session)
 Seeing more collaboration amongst interested parties.

 What's voice application?
 Starts with an audio stream.
 Can connect disparate applications.
 Goes beyond a phone call.

 examples:
 live translation service over the phone or data
 automated reminder calls
 mid-call assistive services
 - bring people in during a call
 crm integration
 over-the-top services of any variety

 telephony doesn't have to be hard
 Adhearsion -- ruby approach to telephony applications
 Voice Application Framework

 Adhearsion sits in the middle, drives a telephony engine and connects it to
 whatever thing you'd like that Ruby can connect to.

 Hosting flexibility -- you can host anywhere they will run Ruby.
 Will run on anything UNIX based. 
 Gives you the ability to interact between calls.
 (drop in and out of calls)
 Simple, extensible API. And it's a real project!
 "gem install adhearsion" and go?
 Not really Asterisk, FreeSwitch and PRISM are still a pain to set up.
 Connectivitiy is PITA
 Cloud deployment platform? Sure? adhearsion.com/cloud

 WebRTC democratized real-time voice & video communications
 but encourages silos
 need to integrate with public networks
 allow a range of endpoint capabilities
 adhearsion makes a good web-thingy for webrtc
 adhearsion does not directly handle media or signals
 purely a 3rd party control component driving VOIP
 Speaks Rato based on XMPP
 supports accessing federated voice networks

 try it out! MojoLingo builds this stuff.


 ---------------------------------------------
 Fred Cheng (simperium)
 Simperium is a hosted platform for synchronizing data

 Sync + Transforms

 Operational Transforms -- a set of transforms to support collaboration
 Operations describe change from one state to another
 Application should generate ops
 Intercept application events
 diffs can be used to generate operations

 --------------------------------------------
 The State of Realtime at &yet
 as it pertains to And Bang 2.0

 What are Web Apps really?
 Web apps are hosted services that are good at some particular kind of data.

 Your API is core to your offering. Everybody builds REST APIs for this.

 Shortcomings to HTTP + REST?
 How do you link one existing object to another?

 Web API is not necessarily REST
 APIs are sets of functionality.

 What do we want from an API?
 Multiple ways to get data in and out (transports, formatst)
 Simple unified auth (settle for OAuth)
 The official app ought to be just another client of the public API
 Full data eventing (if something happens clients should know)

 What about realtime?
 HTTP doesn't do push.
 Websockets
 ServerSent Events
 XMPP
 Socket.io
 Long-Polling
 Animated GIF-Straming?!?


 Throw REST+HTTP out? Nah.
 HTTP is just one type of transport for your data.
 APIs are functions, HTTP+REST is just one transport.
 Adapters/transports to the one true API.

 Build a spec
 Build everything off of the spec



 =========================================

 Meteor w/Meteor dude Matt
 -------------------------

 Meteor is a JS app framework that makes it "dramatically easier" to write web
 applications.

 What we've learned
 -------------------
 Apps are moving to the client (this is sort of old skool)
 - massive architectural change!
 -- google docs is not a port of ms office
 -- old desktop protocols/tools/languages are not as strong
 -- business model is different
 -- web has brought a new set of tools
 -- HTTP/REST other fundamentals are less critical in the real time web
 --- new shit is coming
 --- opportunity to build new standards
 -- data on the wire makes client side apps


 What comes next
 ---------------
 -- client-side cache
 --- with app on the client we have a latency problem
 --- you have to wait for data from the server
 --- pre-fetch, cache
 --- cache invalidations (still hard) - server pushes new data
 -- remote methods
 --- clients should call semantic methods (not necessarily RESTful)
 --- would be nice if the method would update your local cache immediately
 --- that way you don't need to wait for the server response
 -- there's no standard wire format! (bummer)

 DDP
 ----
 --- wire protocol used in Meteor stack
 --- servers publish sets of documents
 --- clients don't necessarily need to ask
 --- subscribe, and servers will set/unset documents in your client
 --- sub and unsub
 --- clients call methods on remote server
 CALL upvotePost 1 [f2548c]
 RES f2548c "okay"
 --- tie subscriptions and method calls together
 --- server will tell you when all your data has arrived on the server
 --- methods should run once and only once (once per message semantics)
 if you disconnect and call the same method again, server will just send you
 the response without running the method again
 --- Hey look! A real time API (pub/sub with remote method invocation)
 --- does interoperability real good! Not specific to JS
 --- you get common tooling between front and back end
 --- you can build really interesting real-time apps fast and not worry about
 cache invalidation.
 --- keep it simple and it will be rad
 (check DDP out: http://meteor.com/blog/2012/03/21/introducing-ddp)

 JS is kinda sorta homoiconic which makes this pretty cool when implemented that
 way. Clojure is also homoiconic, so that rocks too (CJScript + CJ)
 ==========================================================================

 Owen Barnes -- SocketStream
 ----------------------------
 - a node framework for single-page apps
 - all data comes over a websocket 

 3 phases of web
 ----------------
 Static
 -- don't do shit
 Dynamic
 -- snapshot
 Realtime
 -- responsive, not a snapshot

 "Why no use Socket.io?"
 - you can, transport layer is swappable


 =============================================================================

 Daniel Shaw - Observability for node & realtime software (at scale)
 @dshaw
 voxer
 -------------------------------------------------------------------
 Observability is pretty hard esp at scale
 -- you can't grep that 
 Realtime app priorities
 - Scalability
 - Observability
 Scale is why we build realtime apps. Observability is how we mainain the scale.
 Sometime things get out of control, we should know what's going on.

 Tools
 -----
 - logging
  don't be afraid
  limiting logging is a premature optimization
  but you can go too far
  too much noise, too much serialization of large objects
 - heartbeat/health/status endpoints
  memory, uptime, version, pid, connection etc...
  (not specific to node, but we've got some nodey examples...)
 - REPL
  node supports REPL because it's JS, you can drop in an observe state
  (use a socket). Other languages do that too.
  Restart loses those insights.
  (there's a node module called replify for doing this in node)
  domain sockets are good if you want everything to be secure, but you can use
  tcp if you like

 aggregates and lossy things....
 - log aggregation
  loggly
  graylog2
  splunk
  winston(d)
  files + grep (hahaha)
 - monitoring
  boundary
  nagios
  reconnoiter
  ciconnus
  munin
 - metrics
  statsd
  mockingbird
  something new from voxer...
  llquantize will give you many insights
  tell a story with visualization, comparative analysis, system health, 
  event triggers
 - DTrace
  http://en.wikipedia.org/wiki/DTrace

 all of this onservability is constantly growing, ongoing, neverending story
 great photo of paula deen riding that dog thing

 ====================================================

 Lightning node.js dev
 ---------------------
 This cat writes node at MS(Glen Block @gblock)

 apps and (node apps) are moving to the cloud
 azure can do all the things their competitors do, recognize
 this is essentially an ad for Windows Azure. Hey it does all that stuff Heroku does.
 Node!

 deploying node fast and continually to azure!
 azure cli allows for deployment via Git a'la Heroku
 ========================================================

 Peter Saint-Andre -- Jabber, CISCO, presence
 --------------------------------------------
 presence!
 presence is key to IM.
 The original real-time tech.
 XMPP/Jabber has been around since 1999.
 (Extensible messaging and presence protocol)

 XMPP has generic pubsub, and pubsub for presence
 presence is availability, attention, focus etc...
 security is important -- SSL/TLS is not enough
 internationalization matters (Unicode/UTF-8 is not enough)
 federation matters
 - single service silos provide a single point of failure
 decentralized tech is the Right Way

 is presence still relevant?
 - yes but not so exciting
 - key for un-social apps like IM and collaboration (1 on 1)
 - trigger for spontaneous or intensive interaction
 - presence is now stable and well known via XMPP
 - opportunities still exist

 not just for people
 - machines can have presence to
 -- components, bots, etc...

 challenging to manage multiple presence endpoints
 - needed: better client-side composition and presentation for presence
 - like: superfeedr for presence

 we can build on presence
 - augment with device capabilities
 - extended presence, ambient info, mood, geo etc...

 more interaction  in mobile and web
 - more and better presence in mobile apps
 - per-app presence in browsers
 - XMPP over websocket

 don't be scared by the x in xmpp
 - angle brackets not required
 - easy to use web apis

 too many people are working synchronously
 - sending shit over e-mail
 - builing more interactive ways to work together

 presence + rtc is a big opportunity
 big silos have good presence, but your app has it too
 don't be a small silo
 use xmpp to share presence across domains
 federate or die, share presence across borders with open protocol
 presence is the dialtone for realtime internet
 catalyst for realtime interaction and byproduct of realtime interaction
 we've solved the problem, use XMPP

 ============================================================================

 Re-thinking OAuth (or fuck OAuth)
 ---------------------------------
 this dude doesn't like cats
 can't apologize enough for OAuth

 Why does OAuth suck?
 - OAuth1 doesn't use https
 - no user metadata
 - lame requirements
 - php4 compatible
 - worlds worst hosting (no https)
 - good enough for google to deploy (secure)
 - not openid!

 Pain
 - signatures
 - broken libaries
 - provider extensions
 - crappy spec

 The scam
 - promote no signatures
 - require token refresh
 - signatures < stateful client
 - roundtrips required

 Why does OAuth2 suck
 - not a protocol
 - too extensible
 - refresh tokens
 - no interoperability
 - framework (not protocol -- breaks interoperability)
 - assertions (saml, jwt)
 - no signatures (they could be not so bad now)
 - hosted applications centric (doesn't care about mobile, native or browser apps)
 -- server hosted, server rendered html apps

 Why did this happen?
 - YOU! (you keep using)
 - enterprise (motivated by whack requirements)
 - MS and Google (consumers aren't represented, weird use cases, wouldn't allow for strictness)
 - openid (couldn't make openid incompatible changes)
 - ietf (organization is turrible)

 Security (Theater)
 - Public clients
 -- no secrets
 -- url hijacking
 -- malware
 end up with terrible stuff like webviews for OAuth authentication
 custom schemes (for redirecting to app) get stepped on
 android solves this with choice dialog, but iOS doesn't
 webviews can steal user/pass anyhow, so it's actually not secure
 just give the app user/pass

 Bearer tokens
 - client side enforcement
 signatures tend to solve this problem
 - no client bindings
 token is not bound to client
 2 apps can share the same token, for example
 (if you can get a valid token, you can use it in any client)
 facebook added custom exception to solve this (fuuuuuck)

 What should I implement?
 - NO good answer
 - OAuth1 doesn't scale for large orgs
 - OAuth2 needs security expertise to make it effective
 -- need to add secret sauce on top of token
 -- derive encryption key using salt1
 -- derive mac key using salt2
 -- generate random iv
 -- encrypt then mac(salt1 + iv + data)
 -- transmit salt1,2 iv and encrypted

 Oauth1 was success because of community
 Standards make things worse for something like this
 - $ centric
 - ipr bullshit
 - unaccountable leadership
 - takes for-fucking-ever
 -- 3 years for OAuth2 spec
 -- okay for JS, where stability is important


 New solution!
 OZ
 - OSS
 - implementation first
 -- working implementation, then spec after
 - consumer centric web
 -- fuck the enterprise, nobody cares
 - allows for mobile and native
 -- design for things that people actually use
 - realtime & support beyond HTTP
 -- don't bing to protocol

 outline
 - user/pass on native
 - Oauth 2 flows are optional
 - auto configuration
 -- changeable, not compiled into applications/servers
 - encapsulated tickets

 lower expectations!
 - nothing here....
 - looking for contributors
 github.com/hueniverse/oz

 Eran Hammer (@eranhammer)

 ==================================

 Johnny-five is node module for arduino
 so you can arduino with node, and use websockets to send things back and forth
 https://github.com/rwldrn/johnny-five


 =====================================
 Brian Beggs - EnerNOC (Enabling EnerNOC's Realtime Data)
 ---------------------------------------------------------
 Smart Grid + Green Energy
 Shut your shit off.

 Grid operators need to be able to meet peak demand
 can't just bring on a new plant
 spinning reserve plants are very dirty
 EnerNOC gets $ from grid operators and splits it with consumers for shutting shit off.
 Looking into building small meters

 Why is this cool realtime stuff?
 We have to know who is using electricity where at any time.
 4 million readings/day processed persisted and ready for use.
 Not just DR data, but efficiency occupancy and weather too.

 data needs to be realtime and fast, so we known shit is being shut off.
 have to reconcile with grid operators and other stakeholders.

 Past
 ----
 Software is actually super duper old.
 Oracle, flex, jboss, seam (crappy old Java shit)
 Beholden to Oracle in a big way
 Hardware is not great either, SDKs are rought, access to OS is restricted

 Future
 -----
 New hardware
 focus on componentizing systems, using contributing to FOSS, right tool for the job, not the tool you're accustomed to, build good products, not just meet requirements
 moving to ruby, python
 bummers: highly regulated, interfacing with clients that aren't moving at the same rate
 Need to be highly reliable

 First!
 New hardware
 reduce installation time and cost, and add wirelessness (meter runs embedded linux, python, and use xmpp for presence)

 XMPP enables smart clients, bi-direction comm. easy way through client firewalls
 - widely used and understood
 - file transfer is backed in 
 - very easy to extend
 - SleekXMPP

 Some challenges with xmpp
 - 90% of installations are cellular
 - socket tends to fail silently
 - since xmpp messagse doesn't get a response, might be writing to a black hole
 - XML (it sucks)

 Dealing with it
 - small name spaces, taga dn attributes
 - periodic ping to server to ensure connection during inactivity
 - implemtn xep-0198 stream management gets you acks for messages
 - set custom timeouts for send and receive at socket level (Python!)

 New data storage
 - relational dbs are whack
 - storing time series or logging, pretty slow, indexes grow larger than data
 - doesn't shard so great

 non rel with Mongo
 - sharding just works
 - suited to the type of data
 - bucketing
 - small keys
 - pre-allocated stub docs
 - hashed ids for data locality

 now can provide an api for the meter data
 - provides on-the-fly aggregations of data
 not really realtime

 workflow
 --------
 client connect to node server with socket.io
 click on point or site
 new request to hardware is sent, and realtime data gets sent back

 You can see shit getting shut off in real time

 you can disrupt even in the enterprise, hire right people, use the right tools

 (check out sleekXMPP https://github.com/fritzy/SleekXMPP)

 ===============================================================
 Bob Wyman (lightning talk!)
 ---------------------------
 demo app, frackim (Prospective Search)
 relational (retrospective) databases  -- in the past, have you seen this thing?

 realtime -- not interested in the past, you want to know what happened.
 prospective database indexes queries, to tell you what's going to happen.
 completely different set of technologies.

 everything that was in pubsub.com (100s of Ks LOC), now about 100 LOC (with app engine)
 =================================================================

 Luigi Montavez - Deep Dive into Server-Sent Events
 --------------------------------------------------
 Part of HTML5 now
 Try 'em you'll like it

 Realtime updates to the web, no page refresh
 long polling is a hack, and is a sucky way to implement comet

 Websockets
 tcp browser -> server, bi-directional. low level, you must define protocol.
 you can do xmpp, irc, amqp, vnc or whatever
 no js polyfill, gotta fallback to flash or simliar

 Server-Sent events
 forgotten sibling of websockets
 push only, downstream server -> client
 browser handles reconnections
 no need for flash fallbacks (js polyfills exists for shitty browsers)

 Use-cases
 stock ticker, analytics, twitter-style social feed, notifications from server

 Implementing in the browser
 ---------------------------
 var source = new EventSource("/stream");
 source.addEventListener("message"....);
 source.addEventListener("open" ...);
 source.addEventListener("error"...);

 listeners take event e, and can use e.data (message contents). You could send a string or maybe even a JSON object.
 also includes retry, id, and event
 browser will pass last event id to server so we can replay events that we missed
 retry determines retry interval in millis
 event is an event type, so you can add listeners for that type of event

 all browsers 'cept android browser and IE support it
 good news!
 there are polyfills for those browsers that have no support
 (github.com/remy/polyfills github.com/Yaffle/EventSource github.com/rwldrn/jquery.EventSource)

 CORS support coming soon! (plus polyfills support it already -- in FF and Opera, Patch in for Webkit)

 On the server
 -------------
 accept text/event-stream header in request
 look for the path to your sse path, then send the event

 response is "text/event-stream", send id, event, and data in payload

 pretty simple in node, can be done in other things too (construct and send JSON)

 Rails 4 does it too! (examples)
 (django-sse is a thing for real people like us to use)
 Ship it!

 good bridge technology, provides a sprinkling of realtime downstream push to conventional webapps
 simple, easy to implement, anti-complexity philosophy

 ================================================================================================