From 3a27b3092ea9b34c88a3210c61ecdc0581a2a38d Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Mon, 5 Oct 2015 10:32:37 +0200 Subject: fixing sphinx warnings --- api-merchant.rst | 65 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 33 insertions(+), 32 deletions(-) (limited to 'api-merchant.rst') diff --git a/api-merchant.rst b/api-merchant.rst index 8cc51259..54ea87bc 100644 --- a/api-merchant.rst +++ b/api-merchant.rst @@ -87,29 +87,30 @@ Encodings +++++++++ The used encoding are the same described in :ref:`encodings-ref`, with the addition -of the `contract`'s and `deposit permission`'s blobs +of the `contract`'s and `deposit permission`'s blobs. .. _contract: - * **contract**: -The following structure is mainly addressed to the wallet, that is -in charge of verifying and dissecting it. It is not of any interest -to the frontend developer, except that forwarding the JSON that encloses -it. However, refer to the `gnunet `_'s documentation -for those fields prepended with `GNUNET_`. + * **contract**: + The following structure is mainly addressed to the + wallet, that is in charge of verifying and dissecting it. It is + not of any interest to the frontend developer, except that + forwarding the JSON that encloses it. However, refer to the + `gnunet `_'s documentation for those fields + prepended with `GNUNET_`. -.. sourcecode:: c + .. sourcecode:: c - struct Contract - { - struct GNUNET_CRYPTO_EddsaSignature sig; // signature of the contract itself: from 'purpose' field down below. - struct GNUNET_CRYPTO_EccSignaturePurpose purpose; // contract's purpose, indicating TALER_SIGNATURE_MERCHANT_CONTRACT. - char m[13]; // contract's id. - struct GNUNET_TIME_AbsoluteNBO t; // the contract's generation time. - struct TALER_AmountNBO amount; // the good's price. - struct GNUNET_HashCode h_wire; // merchant's bank account details hashed with a nounce. - char a[]; // a human-readable description of this deal, or product. - } + struct Contract + { + struct GNUNET_CRYPTO_EddsaSignature sig; // signature of the contract itself: from 'purpose' field down below. + struct GNUNET_CRYPTO_EccSignaturePurpose purpose; // contract's purpose, indicating TALER_SIGNATURE_MERCHANT_CONTRACT. + char m[13]; // contract's id. // FIXME: this should be a uint64_t! + struct GNUNET_TIME_AbsoluteNBO t; // the contract's generation time. + struct TALER_AmountNBO amount; // the good's price. + struct GNUNET_HashCode h_wire; // merchant's bank account details, hashed with a nounce. + char a[]; // a human-readable description of this deal, or product. // FIXME: this should be the hash of the JSON! + } .. _deposit permission: @@ -215,7 +216,7 @@ The following are the API made available by the merchant's frontend to the walle It is worth showing a simple code sample. - .. sourcecode:: js + .. sourcecode:: js function checkout(form){ for(var cnt=0; cnt < form.group1.length; cnt++){ @@ -249,18 +250,18 @@ The following are the API made available by the merchant's frontend to the walle document.body.dispatchEvent(cevent); }; - In this example, the function `checkout` is the one attached to the - 'checkout' button (or some merchant-dependent triggering - mechanism). This function issues the required POST and hooks the - function `sendContract` as the handler of the successful case - (i.e. response code is 200). The hook then simply dispatches on the - page's `body` element the 'taler-contract' event, by passing the - gotten JSON as a further argument, which the wallet is waiting for. + In this example, the function `checkout` is the one attached to the + 'checkout' button (or some merchant-dependent triggering + mechanism). This function issues the required POST and hooks the + function `sendContract` as the handler of the successful case + (i.e. response code is 200). The hook then simply dispatches on the + page's `body` element the 'taler-contract' event, by passing the + gotten JSON as a further argument, which the wallet is waiting for. -.. note:: - Merchants should remind their customers to enable cookies acceptance while - browsing on the shop, otherwise it could get difficult to associate purchase's - metadata to its intended certificate. + .. note:: + Merchants should remind their customers to enable cookies acceptance while + browsing on the shop, otherwise it could get difficult to associate purchase's + metadata to its intended certificate. **Success Response** @@ -297,7 +298,7 @@ The following are the API made available by the merchant's frontend to the walle **Success Response: OK** :status 200 OK: the payment has been received. - **Failure Response: TBD ** + **Failure Response: TBD** **Error Response: Invalid signature** @@ -347,7 +348,7 @@ The following API are made available by the merchant's backend to the merchant's :