gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: -db recommendation


From: gnunet
Subject: [taler-docs] branch master updated: -db recommendation
Date: Tue, 28 Mar 2023 13:39:59 +0200

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 74b9876  -db recommendation
74b9876 is described below

commit 74b98766d448602ef24461ec52aa33bfdfa73b6d
Author: Florian Dold <florian@dold.me>
AuthorDate: Tue Mar 28 13:39:55 2023 +0200

    -db recommendation
---
 design-documents/033-synchetic-wallet-errors.rst | 57 ++++++++++++++++++++++++
 design-documents/040-distro-packaging.rst        | 17 ++++++-
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/design-documents/033-synchetic-wallet-errors.rst 
b/design-documents/033-synchetic-wallet-errors.rst
new file mode 100644
index 0000000..962e2dc
--- /dev/null
+++ b/design-documents/033-synchetic-wallet-errors.rst
@@ -0,0 +1,57 @@
+Design Doc 033: Dev Experiments
+###############################
+
+Summary
+=======
+
+This design document defines new ``taler://`` URIs to cause synthetic errors
+or special states in the wallet that can then be rendered by the UI.
+
+Motivation
+==========
+
+UIs need to handle various (error-) states and responses of wallet-core.  It's
+not easy to cover all of these states and responses manually.  Some of them are
+hard to reach or simulate without an elaborate test setup.
+
+Requirements
+============
+
+The implementation of synthetic errors should be as separate from production
+code as possible, to avoid making the normal code paths unreadable.
+
+
+Proposed Solution
+=================
+
+Special taler:// URIs
+---------------------
+
+* ``taler://dev-experiment/$STATE_ID``
+* ``taler://pay/...?dev-experiment=``
+
+Special http(s):// URIs
+-----------------------
+
+* ``http(s)://*.dev-experiment.taler.net/``
+ 
+  * URLs for this subdomain are handled specially by the
+    wallet's HTTP layer and return fixed / mocked responses
+    instead of making real requests.
+
+
+List of experiments
+-------------------
+
+
+
+Alternatives
+============
+
+Drawbacks
+=========
+
+Discussion / Q&A
+================
+
+(This should be filled in with results from discussions on mailing lists / 
personal communication.)
diff --git a/design-documents/040-distro-packaging.rst 
b/design-documents/040-distro-packaging.rst
index b9c8253..8e52c57 100644
--- a/design-documents/040-distro-packaging.rst
+++ b/design-documents/040-distro-packaging.rst
@@ -87,9 +87,9 @@ Database
 
 Packages should *not* use ``dbconfig-common``.  Reasons are:
 
-* ``debconfig-common`` is lacking in documentation and very difficult
+* ``dbconfig-common`` is lacking in documentation and very difficult
   to use for packagers.
-* ``debconfig-common`` offers too much flexibility and
+* ``dbconfig-common`` offers too much flexibility and
   asks too many questions to the administrator, especially when
   reconfiguring a package. The ``taler-merchant`` package
   currently breaks when the user chooses anything else than ``ident`` auth.
@@ -99,6 +99,19 @@ Packages should *not* use ``dbconfig-common``.  Reasons are:
 * Very few packages in Debian (<30) actually use ``dbconfig-common``;
   even fewer are notable or widely used packages.
 
+Instead, each package should document how to set up
+the database and *optionally* ship an executable named
+``taler-$component-dbconfig`` that:
+
+1. Creates the database and adjusts permissions
+2. Checks if the database is accessible
+3. Runs ``taler-$component-dbinit`` if applicable
+   and unless supressed by the user.
+
+For now, our tooling shall only support PostgreSQL and only set up ``ident``
+authentication or set up ``password`` authentication with a random password for
+components that do not support DB connections via unix domain sockets.
+
 Definition of Done
 ==================
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]