[taler-docs] branch master updated: remove outdated docs

[gnunet]

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 3eb33af5 remove outdated docs
3eb33af5 is described below

commit 3eb33af5fc814b512e5156140235ccb64c0cc86a
Author: Florian Dold <florian@dold.me>
AuthorDate: Mon Sep 4 13:18:06 2023 +0200

    remove outdated docs
---
 core/api-bank-sandbox-future.rst | 152 ---------------------------------------
 core/api-bank.rst                |   1 -
 2 files changed, 153 deletions(-)

diff --git a/core/api-bank-sandbox-future.rst b/core/api-bank-sandbox-future.rst
deleted file mode 100644
index 01583f21..00000000
--- a/core/api-bank-sandbox-future.rst
+++ /dev/null
@@ -1,152 +0,0 @@
-..
-  This file is part of GNU TALER.
-
-  Copyright (C) 2014-2020 Taler Systems SA
-
-  TALER is free software; you can redistribute it and/or modify it under the
-  terms of the GNU Affero General Public License as published by the Free 
Software
-  Foundation; either version 2.1, or (at your option) any later version.
-
-  TALER is distributed in the hope that it will be useful, but WITHOUT ANY
-  WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
-  A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more 
details.
-
-  You should have received a copy of the GNU Affero General Public License 
along with
-  TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
-
-
-Future Sandbox API
-##################
-
-Resources.
-^^^^^^^^^^
-
-Sandbox serves the following resources:
-
- - Demobanks.
- - Bank accounts.
- - Subscribers.
- - Transactions.
- - Customers.
- - Reports.
-
-The resources are subject to all CRUD operations, via by two
-types of users: the 'admin' and the customers.  The admin has
-rights on all of them.
-
-One of the main differences with the previous versions is the
-removal of the "/admin" initial component.  If the administrator
-authenticates for one operation, then this one is of type ``admin``:
-no need for a dedicated and extra URI path component.
-
-For example, mocking transactions in the system was a typical
-/admin-operation, but since transactions themselves are resources
-and any resource is subject to CRUD operations, then mocking one
-becomes just a ``C`` operation on the 'transactions' resources.  If
-a test case wants to simplify the authentication - by hard-coding
-the credentials, for example - before mocking one transaction, then
-it can impersonate the administrator.
-
-.. note::
-
-   ``POST``\ ing to an endpoint with a trailing ``$id`` means
-   modification of an existing resource.
-
-Demobanks
-^^^^^^^^^
-
-Demobanks are the main containers of all the other resources.
-They take configuration values, like the currency for example.
-
-.. http:get:: /admin/demobanks
-.. http:get:: /admin/demobanks/$id
-.. http:post:: /admin/demobanks
-.. http:post:: /admin/demobanks/$id
-.. http:delete:: /admin/demobanks/$id
-
-Bank accounts.
-^^^^^^^^^^^^^^
-
-Bank accounts collect money of customers and participate
-in transactions.
-
-The ``$base`` is one demobank, in the form ``/demobanks/$id``.
-That is due because a bank account must inherit some defaults
-from the demobank, like the currency.
-
-.. http:get:: $base/bankaccounts
-.. http:get:: $base/bankaccounts/$id
-.. http:post:: $base/bankaccounts
-.. http:post:: $base/bankaccounts/$id
-.. http:delete:: $base/bankaccounts/$id
-
-Subscribers.
-^^^^^^^^^^^^
-
-Subscribers are (optional) customers identities for protocols
-other than the native one.
-
-A subscriber is not required to have a bank account "soon".  Therefore,
-it can be created, and later be linked to one bank account.  For this
-reason, the ``$base`` should not mention one bank account.
-
-.. note::
-
-   Creating a subscriber is a time-consuming operation that goes often
-   through slow channels, therefore it should basically never be done
-   more than once.
-
-.. http:get:: $base/subscribers
-.. http:get:: $base/subscribers/$id
-.. http:post:: $base/subscribers
-.. http:post:: $base/subscribers/$id
-.. http:delete:: $base/subscribers/$id
-
-Transactions.
-^^^^^^^^^^^^^
-
-Transactions are money movements between bank accounts.
-
-For convenience, ``$base`` **could** mention one bank account
-to let customers see their transactions without defining "history"
-query parameters: like ``$demobank/bankaccounts/$bankaccountId/transactions``.
-
-At the same time, transactions should be easy to query regardless
-of whose bank account they involve -- for administrative reasons, for
-example.  Hence, a "global" URI scheme like 
``$demobank/transactions?param=XXX``
-should be offered as well.
-
-.. http:get:: $base/transactions
-.. http:get:: $base/transactions/$id
-.. http:post:: $base/transactions
-.. http:post:: $base/transactions/$id
-.. http:delete:: $base/transactions/$id
-
-Customers.
-^^^^^^^^^^
-
-Customers are persons that **can** have one bank account.  As
-with subscribers, ``$base`` should not mention any bank account
-so as to leave more flexibility to assign new bank accounts to
-the same customer.
-
-.. http:get:: $base/customers
-.. http:get:: $base/customers/$id
-.. http:post:: $base/customers
-.. http:post:: $base/customers/$id
-.. http:delete:: $base/customers/$id
-
-Reports.
-^^^^^^^^
-
-Reports are persistent documents witnessing transactions.
-A typical example is a Camt.053 statement.  A report lives
-even after a bank account gets deleted or a customer leaves
-the bank, therefore ``$base`` should only mention a demobank
-instance.
-
-.. http:get:: $base/reports
-.. http:get:: $base/reports/$id
-.. http:post:: $base/reports
-.. http:post:: $base/reports/$id
-.. http:delete:: $base/reports/$id
diff --git a/core/api-bank.rst b/core/api-bank.rst
index 576e1b27..13524b72 100644
--- a/core/api-bank.rst
+++ b/core/api-bank.rst
@@ -33,7 +33,6 @@ Bank RESTful APIs
   api-bank-access
   api-bank-nexus
   api-bank-sandbox
-  api-bank-sandbox-future
   
 
 .. toctree::

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