ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Edits for style

Browse Source
This commit is contained in:
mDuo13
2021-05-28 16:45:42 -07:00
parent fd21b84d11
commit b5a7a4870e
31 changed files with 64 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md
View File

@@ -8,12 +8,12 @@ blurb: Lists of prior ledger versions' hashes for history lookup.
(Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.)
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically in the process of closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains:
- Exactly one "recent history" `LedgerHashes` object
- A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions.
- A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions. <!-- STYLE_OVERRIDE: a number of -->
**Note:** As an exception, a new genesis ledger has no `LedgerHashes` objects at all, because it has no ledger history.

2
content/references/protocol-reference/serialization.md
View File

@@ -56,7 +56,7 @@ Additionally, the following libraries also provide serialization support:
{% include '_snippets/libs-snippet.md' %}
These implementations are all provided with permissive open-source licenses, so you can import, use, or adapt the code for your needs in addition to using it alongside these documents for learning purposes.
These implementations are all provided with permissive open-source licenses, so you can import, use, or adapt the code for your needs.

2
content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md
View File

@@ -6,7 +6,7 @@ template: template-landing-children.html
---
# Pseudo-Transactions
Pseudo-transactions are never submitted by users, nor [propagated through the network](peer-protocol.html). Instead, a server may choose to inject pseudo-transactions in a proposed ledger directly according to specific protocol rules. If enough servers inject an identical pseudo-transaction for it to be approved by the [consensus process](consensus.html), then the pseudo-transaction becomes included in the ledger, and appears in ledger data thereafter.
Pseudo-transactions are never submitted by users, nor [propagated through the network](peer-protocol.html). Instead, a server may choose to inject pseudo-transactions in a proposed ledger directly according to specific protocol rules. If enough servers propose the exact same pseudo-transaction, the [consensus process](consensus.html) approves it, and the pseudo-transaction is included in that ledger's transaction data.
## Special Values for Common Fields

6
content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md
View File

@@ -30,11 +30,11 @@ The following script is a sample that can be created as `/etc/logrotate.d/ripple
}
```
You can configure parameters such as `minsize` and `rotate` depending on the amount of logs you keep. Use the `log_level` setting in your `rippled.cfg` file to configure how verbose your server's logs are. This sample script is based on standard `log_level` and will store approximately 2 weeks worth of logs in a compressed format.
You can configure parameters such as `minsize` and `rotate` depending on the amount of logs you keep. Use the `log_level` setting in your `rippled.cfg` file to configure how verbose your server's logs are. This sample script is based on standard `log_level` and stores approximately 2 weeks worth of logs in a compressed format.
Starting with `rippled` 1.3, the script `/etc/logrotate.d/rippled` will be automatically installed by the DEB and RPM packages. You can make modifications to this as required. Your modifications will not be overwritten on package upgrades.
The official packages [for CentOS/Red Hat](install-rippled-on-centos-rhel-with-yum.html) and [Ubuntu or Debian](install-rippled-on-ubuntu.html) provide the script `/etc/logrotate.d/rippled` by default. You can make modifications to this as required. Your modifications will not be overwritten on package upgrades. <!-- STYLE_OVERRIDE: will -->
**Note:** You should have only one system logrotate script per application. Please ensure that you do not have any other log rotation that handles the same directory.
**Note:** You should have only one system log rotation script per application. Please ensure that you do not have any other log rotation that handles the same directory.
_The `logrotate` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._

2
content/references/rippled-api/api-conventions/api-conventions.md
View File

@@ -8,4 +8,4 @@ template: template-landing-children.html
This section describes data types and formats of the HTTP APIs (JSON-RPC and WebSocket) as implemented in [the `rippled` server](the-rippled-server.html).
For information regarding the XRP Ledger protocol regardless of interface, see [Protocol Reference](protocol-reference.html).
For information on the XRP Ledger protocol that applies to all APIs, see [Protocol Reference](protocol-reference.html).

4
content/references/rippled-api/api-conventions/response-formatting.md
View File

@@ -16,7 +16,7 @@ The fields of a successful response include:
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. |
| `type` | String | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. |
| `result` | Object | The result of the query; contents vary depending on the command. |
| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.html) threshold where the server will disconnect this client. |
| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.html) threshold where the server will disconnect this client. <!-- STYLE_OVERRIDE: will --> |
| `warnings` | Array | _(May be omitted)_ If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). [New in: rippled 1.5.0][] |
| `forwarded` | Boolean | _(May be omitted)_ If `true`, this request and response have been forwarded from a [Reporting Mode][] server to a P2P Mode server (and back) because the request requires data that is not available in Reporting Mode. The default is `false`. |
@@ -126,7 +126,7 @@ Example warning:
]
```
This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible.
This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. <!-- STYLE_OVERRIDE: will -->
The server only sends this warning if the client is [connected as an admin](get-started-using-http-websocket-apis.html#admin-access).