Cleanup some of the example code & docs

This commit makes a set of small adjustments to examples.

- Rework some of the comments to be more clear.
- Add links to the original source tree file.
- Rename some of the examples to make it clear the
  concept the example is intented to show.
- Move some common example functionality to the
  example utility file.

Change-Id: I858e0dbf72fe8cb40a05bfdbb0857720ffb71c7f

1 files changed, 5 insertions, 11 deletions

diff --git a/taskflow/examples/reverting_linear.py b/taskflow/examples/reverting_linear.py
index e6e5bb0..f912fa9 100644
--- a/taskflow/examples/reverting_linear.py
+++ b/taskflow/examples/reverting_linear.py
@@ -31,21 +31,15 @@ from taskflow.patterns import linear_flow as lf
 from taskflow import task
 
 # INTRO: In this example we create three tasks, each of which ~calls~ a given
-# number (provided as a function input), one of those tasks fails calling a
+# number (provided as a function input), one of those tasks *fails* calling a
 # given number (the suzzie calling); this causes the workflow to enter the
 # reverting process, which activates the revert methods of the previous two
 # phone ~calls~.
 #
 # This simulated calling makes it appear like all three calls occur or all
 # three don't occur (transaction-like capabilities). No persistence layer is
-# used here so reverting and executing will not handle process failure.
-#
-# This example shows a basic usage of the taskflow structures without involving
-# the complexity of persistence. Using the structures that taskflow provides
-# via tasks and flows makes it possible for you to easily at a later time
-# hook in a persistence layer (and then gain the functionality that offers)
-# when you decide the complexity of adding that layer in is 'worth it' for your
-# applications usage pattern (which some applications may not need).
+# used here so reverting and executing will *not* be tolerant of process
+# failure.
 
 
 class CallJim(task.Task):
@@ -94,6 +88,6 @@ except Exception as e:
     # how to deal with multiple tasks failing while running.
     #
     # You will also note that this is not a problem in this case since no
-    # parallelism is involved; this is ensured by the usage of a linear flow,
-    # which runs serially as well as the default engine type which is 'serial'.
+    # parallelism is involved; this is ensured by the usage of a linear flow
+    # and the default engine type which is 'serial' vs being 'parallel'.
     print("Flow failed: %s" % e)