From 56e3f6075fb0c4bc9ce19abfe9e4b16c6ab64535 Mon Sep 17 00:00:00 2001
From: Eric Blake <eblake@redhat.com>
Date: Wed, 30 Oct 2019 17:17:55 +0100
Subject: [PATCH] 8400: Replace <pre> graph with <table>.

---
 .../8400-tradeoff-complexity-issues.html           | 65 ++++++++++++++--------
 1 file changed, 43 insertions(+), 22 deletions(-)

diff --git a/2019-kvm-forum/8400-tradeoff-complexity-issues.html b/2019-kvm-forum/8400-tradeoff-complexity-issues.html
index 8208350..f3c0ba3 100644
--- a/2019-kvm-forum/8400-tradeoff-complexity-issues.html
+++ b/2019-kvm-forum/8400-tradeoff-complexity-issues.html
@@ -5,26 +5,47 @@
 <h1>Tradeoff: how much complexity</h1>
 
 <p>
-  Filler - summarize various options. Maybe a 2-d graph with:
-
-  <pre>
-    c |
-    l |
- ^  i |
-    e |
- i  n |
- n  t |  multiple knobs,
- c    |  requires multiple
- r  c |  fallbacks, but a
- e  o |  non-SR solution works
- a  m |
- s  p |
- i  l |
- n  e |
- g  x |                           require more uniformity,
-    i |                           interop testing is easier,
-    t |                           but writing correct server
-    y |                           requires more effort
-      +------------------------------------------------------
-         > increasing server complexity
+  Tradeoffs in implementation complexity
+  <table id="border">
+    <tr>
+      <th style="width:8%;"></th>
+      <th>Lots of knobs in the NBD spec</th>
+      <th>Mandate all-or-none server implementation</th>
+    </tr>
+    <tr>
+      <td style="text-align:center;">Pro</td>
+      <td>
+	<ul>
+	  <li>Implement as much or as little as convenient for the
+	    server
+	  <li>Matches reality that no one resize solution fits all
+	</ul>
+      </td>
+      <td>
+	<ul>
+	  <li>Easier interoperability testing
+	  <li>Client can rely on all servers giving same response
+	</ul>
+      </td>
+    </tr>
+    <tr>
+      <td style="text-align:center;">Con</td>
+      <td>
+      	<ul>
+	  <li>More combinations requires more testing
+	  <li>Odd or untested combinations could produce weird
+	    behaviors or even CVEs
+	  <li>Clients must be prepared for more fallbacks
+	  <li>NBD protocol tries to be as simple as possible
+	</ul>
+      </td>
+      <td>
+	<ul>
+	  <li>Not all tradeoffs map easily to existing implementation
+	  <li>Open-ended structured replies requires more efforts for
+	    writing a compliant server
+	</ul>
+      </td>
+    </tr>
+  </table>
 </p>
-- 
1.8.3.1