From d8935bdbcb00f1b403293a3087d6af8648ffecd4 Mon Sep 17 00:00:00 2001
From: Andrew Wilcox <andrew.wilcox@gmail.com>
Date: Fri, 8 Nov 2013 13:47:36 -0500
Subject: [PATCH] Update description of deprecated DDP welcome message and
 include QA notes.

---
 packages/autoupdate/QA.md | 85 +++++++++++++++++++++++++++++++++++++++
 packages/livedata/DDP.md  | 10 ++---
 2 files changed, 90 insertions(+), 5 deletions(-)
 create mode 100644 packages/autoupdate/QA.md

diff --git a/packages/autoupdate/QA.md b/packages/autoupdate/QA.md
new file mode 100644
index 0000000000..73a4043327
--- /dev/null
+++ b/packages/autoupdate/QA.md
@@ -0,0 +1,85 @@
+# QA Notes
+
+## Hot Code Push Reload
+
+Run the leaderboard example, and click on one of the names.  Make a
+change to the leaderboard.html file, see the client reload, and see
+that the name is still selected.
+
+
+## Test with the appcache
+
+Add the appcache package:
+
+    $ meteor add appcache
+
+And do the above "Hot Code Push Reload" test again.
+
+
+## No Client Reload on Server-only Change
+
+Undo previous changes made, such as by using `git checkout .` Reload
+the client, which will cause the browser to stop using the app cache.
+
+Note that it might look like the browser is reloading because the page
+content in the leaderboard example will flicker when the server
+restarts because the example is using autopublish, but that the window
+won't actually be reloading.
+
+In the browser console, assign a variable such as `a = true` so that
+you can easily verify that the client hasn't reloaded.
+
+In the leaderboard example directory, create the `server` directory
+and add `foo.js`.  See in the browser console that `a` is still
+defined, indicating the browser hasn't reloaded.
+
+
+## AutoUpdate.newClientAvailable
+
+It's hard to see the `newClientAvailable` reactive variable when the
+client automatically reloads.  Remove the `reload` package so you can
+see the variable without having the client also reload.
+
+    $ meteor remove standard-app-packages
+    $ meteor add meteor webapp logging deps session livedata
+    $ meteor add mongo-livedata templating handlebars check underscore
+    $ meteor add jquery random ejson autoupdate
+
+Add to leaderboard.js:
+
+    Template.leaderboard.available = AutoUpdate.newClientAvailable;
+
+And add {{available}} to the leaderboard template in eaderboard.html.
+
+Initially you'll see `false`, and then when you make a change to the
+leaderboard HTML you'll see the variable change to `true`.  (You won't
+see the new HTML on the client because you disabled reload).
+
+Amusingly, you can undo the addition you made to the HTML and the "new
+client available" variable will go back to `false` (you now don't now
+have client code on the server different than what's running in the
+browser), because by default the client version is based on a hash of
+the client files.
+
+
+## DDP Version Negotiation Failure
+
+A quick way to test DDP version negotiation failure is to force the
+client to use the wrong DDP version.  At the top of
+livedata_connection.js:
+
+     var Connection = function (url, options) {
+        var self = this;
+    +   options.supportedDDPVersions = ['abc'];
+
+You will see the client reload (in the hope that new client code will
+be available that can successfully negotiation the DDP version).  Each
+reload takes longer than the one before, using an exponential backoff.
+
+If you remove the `options.supportedDDPVersions` line and allow the
+client to connect (or manually reload the browser page so you don't
+have to wait), this will reset the exponential backoff counter.
+
+You can verify the counter was reset by adding the line back in a
+second time, and you'll see the reload cycle start over again with
+first reloading quickly, and then again taking longer between tries.
diff --git a/packages/livedata/DDP.md b/packages/livedata/DDP.md
index 8f88889a5d..655f1ca105 100644
--- a/packages/livedata/DDP.md
+++ b/packages/livedata/DDP.md
@@ -37,11 +37,11 @@ depending on message type.
 
 ### Procedure:
 
-The server may send an initial message which is a JSON object lacking a `msg`
-key. If so, the client should ignore it. The client does not have to wait for
-this message. (This message is used to help implement hot code reload over our
-SockJS transport. It is currently sent over websockets as well, but probably
-should not be.)
+The server may send an initial message which is a JSON object lacking
+a `msg` key. If so, the client should ignore it. The client does not
+have to wait for this message. (The message was once used to help
+implement Meteor's hot code reload feature; it is now only included to
+force old clients to update).
 
  * The client sends a `connect` message.
  * If the server is willing to speak the `version` of the protocol specified in