taler-docs

commit 83d93fac315307870830473db52035895bd3cedc
parent f6d23e4c3486899c9e22411b37e2f6e4b0a38d9f
Author: ms <ms@taler.net>
Date:   Mon, 20 Mar 2023 16:04:49 +0100

terminology

Diffstat:
M
design-documents/038-demobanks-protocol-suppliers.rst
 | 
20
++++++++++----------

1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/design-documents/038-demobanks-protocol-suppliers.rst b/design-documents/038-demobanks-protocol-suppliers.rst
@@ -38,10 +38,10 @@ ambiguity and simplify the implementation.
 Suppliers creation
 ==================
 
-Suppliers can be hard-coded into the software or created RESTfully.
+Suppliers can be static or dynamic.
 
-Hard-coded
-^^^^^^^^^^
+Static
+^^^^^^
 
 This supplier never changes its state.  Whether this type
 of supplier is associated or not with a particular demobank
@@ -52,18 +52,18 @@ Examples
 
 1.  A JSON-based protocol that lets users access their bank accounts
 always under the 'default' demobank belongs to this category.  It
-is therefore a 'hard-coded protocol supplier' with static demobank.
+is therefore a 'static protocol supplier' with static demobank.
 
 2.  A XML-based protocol that lets users access their bank accounts
-in a demobank whose name appear in the URI is as well a 'hard-coded
-protocol supplier' but with dynamic demobank.
+in a demobank whose name appear in the URI is as well a 'static protocol
+supplier' with dynamic demobank.
 
 Note: the upcoming (in version 0.9.3) JSON-based supplier that will
-let Nexus reach Sandbox accounts is planned as 'hard-coded protocol
+let Nexus reach Sandbox accounts is planned as a 'dynamic protocol
 supplier' with dynamic demobank.  That allows Taler demos to only
 speak JSON.
 
-RESTful
+Dynamic
 ^^^^^^^
 
 This supplier has a name and its state CAN refer to one
@@ -75,7 +75,7 @@ Examples
 
 1.  A JSON-based protocol that lets users access their bank
 accounts under the demobank whose name is held in the supplier
-state belongs to this category.  It is therefore a RESTful
+state belongs to this category.  It is therefore a dynamic
 supplier with semi-dynamic demobank.
 
 2.  A XML-based protocol that lets user access their bank
@@ -85,7 +85,7 @@ doesn't respect this `mutual exclusivity <demobank-mutually-exclusive_>`_.
 
 3.  A XML-based protocol that lets user access their bank accounts
 always under the 'default' demobank belongs to this category.  It
-is a RESTful supplier with static demobank.  Note: this is the case
+is a dynamic supplier with static demobank.  Note: this is the case
 of EBICS access offered in LibEuFin 0.9.2.
 
 Supplier reachability