From: Eric Blake <eblake@redhat.com>
Date: Wed, 30 Oct 2019 16:17:55 +0000 (+0100)
Subject: 8400: Replace <pre> graph with <table>.
X-Git-Url: http://git.annexia.org/?a=commitdiff_plain;h=56e3f6075fb0c4bc9ce19abfe9e4b16c6ab64535;p=libguestfs-talks.git

8400: Replace <pre> graph with <table>.
---

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>

	Lots of knobs in the NBD spec	Mandate all-or-none server implementation
Pro	+ + Implement as much or as little as convenient for the + server + Matches reality that no one resize solution fits all + +	+ + Easier interoperability testing + Client can rely on all servers giving same response + +
Con	+ + More combinations requires more testing + Odd or untested combinations could produce weird + behaviors or even CVEs + Clients must be prepared for more fallbacks + NBD protocol tries to be as simple as possible + +	+ + Not all tradeoffs map easily to existing implementation + Open-ended structured replies requires more efforts for + writing a compliant server + +