From 2dcd9c223a7f0f24c8947083679bf23264234402 Mon Sep 17 00:00:00 2001
From: Mike Hearn
Date: Fri, 4 Mar 2016 16:15:51 +0100
Subject: [PATCH] Regen docsite
---
docs/build/html/_sources/data-model.txt | 20 +-
docs/build/html/_sources/index.txt | 1 +
.../html/_sources/node-administration.txt | 41 +++
docs/build/html/codestyle.html | 1 +
docs/build/html/data-model.html | 20 +-
docs/build/html/genindex.html | 1 +
docs/build/html/getting-set-up.html | 1 +
docs/build/html/index.html | 5 +
docs/build/html/inthebox.html | 1 +
docs/build/html/messaging.html | 1 +
docs/build/html/node-administration.html | 249 ++++++++++++++++++
docs/build/html/protocol-state-machines.html | 1 +
docs/build/html/roadmap.html | 1 +
docs/build/html/running-the-trading-demo.html | 5 +-
docs/build/html/search.html | 1 +
docs/build/html/searchindex.js | 2 +-
docs/build/html/tutorial.html | 5 +-
docs/build/html/visualiser.html | 1 +
18 files changed, 338 insertions(+), 19 deletions(-)
create mode 100644 docs/build/html/_sources/node-administration.txt
create mode 100644 docs/build/html/node-administration.html
diff --git a/docs/build/html/_sources/data-model.txt b/docs/build/html/_sources/data-model.txt
index 24a73c977a..62d6e3282b 100644
--- a/docs/build/html/_sources/data-model.txt
+++ b/docs/build/html/_sources/data-model.txt
@@ -30,17 +30,23 @@ arguments to the verify function. Each command has a list of **public keys** ass
that the transaction is signed by every key listed in the commands before the contracts start to execute. Public keys
may be random/identityless for privacy, or linked to a well known legal identity via a *public key infrastructure* (PKI).
-Note that there is nothing that explicitly binds together specific inputs, outputs or commands. Instead it's up to the
-contract code to interpret the pieces inside the transaction and ensure they fit together correctly. This is done to
-maximise flexibility for the contract developer.
+Commands are always embedded inside a transaction. Sometimes, there's a larger piece of data that can be reused across
+many different transactions. For this use case, we have **attachments**. Every transaction can refer to zero or more
+attachments by hash. Attachments are always ZIP/JAR files, which may contain arbitrary content. Contract code can then
+access the attachments by opening them as a JarInputStream (this is temporary and will change later).
+
+Note that there is nothing that explicitly binds together specific inputs, outputs, commands or attachments. Instead
+it's up to the contract code to interpret the pieces inside the transaction and ensure they fit together correctly. This
+is done to maximise flexibility for the contract developer.
Transactions may sometimes need to provide a contract with data from the outside world. Examples may include stock
prices, facts about events or the statuses of legal entities (e.g. bankruptcy), and so on. The providers of such
facts are called **oracles** and they provide facts to the ledger by signing transactions that contain commands they
-recognise. The commands contain the fact and the signature shows agreement to that fact. Time is also modelled as
-a fact, with the signature of a special kind of oracle called a **timestamping authority** (TSA). A TSA signs
-a transaction if a pre-defined timestamping command in it defines a after/before time window that includes "true
-time" (i.e. GPS time as calibrated to the US Naval Observatory).
+recognise, or by creating signed attachments. The commands contain the fact and the signature shows agreement to that fact.
+Time is also modelled as a fact, with the signature of a special kind of oracle called a **timestamping authority** (TSA).
+A TSA signs a transaction if a pre-defined timestamping command in it defines a after/before time window that includes
+"true time" (i.e. GPS time as calibrated to the US Naval Observatory). An oracle may prefer to generate a signed
+attachment if the fact it's creating is relatively static and may be referred to over and over again.
As the same terminology often crops up in different distributed ledger designs, let's compare this to other
distributed ledger systems you may be familiar with. You can find more detailed design rationales for why the platform
diff --git a/docs/build/html/_sources/index.txt b/docs/build/html/_sources/index.txt
index 66ce77d925..7d3675f556 100644
--- a/docs/build/html/_sources/index.txt
+++ b/docs/build/html/_sources/index.txt
@@ -28,6 +28,7 @@ Read on to learn:
data-model
messaging
running-the-trading-demo
+ node-administration
.. toctree::
:maxdepth: 2
diff --git a/docs/build/html/_sources/node-administration.txt b/docs/build/html/_sources/node-administration.txt
new file mode 100644
index 0000000000..7f6d13417e
--- /dev/null
+++ b/docs/build/html/_sources/node-administration.txt
@@ -0,0 +1,41 @@
+Node administration
+===================
+
+When a node is running, it exposes an embedded web server that lets you monitor it, upload and download attachments,
+access a REST API and so on.
+
+Uploading and downloading attachments
+-------------------------------------
+
+Attachments are files that add context to and influence the behaviour of transactions. They are always identified by
+hash and they are public, in that they propagate through the network to wherever they are needed.
+
+All attachments are zip files. Thus to upload a file to the ledger you must first wrap it into a zip (or jar) file. Then
+you can upload it by running this command from a UNIX terminal:
+
+.. sourcecode:: shell
+
+ curl -F myfile=@path/to/my/file.zip http://localhost:31338/attachments/upload
+
+The attachment will be identified by the SHA-256 hash of the contents, which you can get by doing:
+
+.. sourcecode:: shell
+
+ shasum -a 256 file.zip
+
+on a Mac or by using ``sha256sum`` on Linux. Alternatively, check the node logs. There is presently no way to manage
+attachments from a GUI.
+
+An attachment may be downloaded by fetching:
+
+.. sourcecode:: shell
+
+ http://localhost:31338/attachments/DECD098666B9657314870E192CED0C3519C2C9D395507A238338F8D003929DE9
+
+where DECD... is of course replaced with the hash identifier of your own attachment. Because attachments are always
+containers, you can also fetch a specific file within the attachment by appending its path, like this:
+
+.. sourcecode:: shell
+
+ http://localhost:31338/attachments/DECD098666B9657314870E192CED0C3519C2C9D395507A238338F8D003929DE9/path/within/zip.txt
+
diff --git a/docs/build/html/codestyle.html b/docs/build/html/codestyle.html
index 1abd344073..f5ac87dd81 100644
--- a/docs/build/html/codestyle.html
+++ b/docs/build/html/codestyle.html
@@ -87,6 +87,7 @@
@@ -173,16 +174,21 @@ the platform does not interpret itself, but which can parameterise execution of
arguments to the verify function. Each command has a list of public keys associated with it. The platform ensures
that the transaction is signed by every key listed in the commands before the contracts start to execute. Public keys
may be random/identityless for privacy, or linked to a well known legal identity via a public key infrastructure (PKI).
-
Note that there is nothing that explicitly binds together specific inputs, outputs or commands. Instead it’s up to the
-contract code to interpret the pieces inside the transaction and ensure they fit together correctly. This is done to
-maximise flexibility for the contract developer.
+
Commands are always embedded inside a transaction. Sometimes, there’s a larger piece of data that can be reused across
+many different transactions. For this use case, we have attachments. Every transaction can refer to zero or more
+attachments by hash. Attachments are always ZIP/JAR files, which may contain arbitrary content. Contract code can then
+access the attachments by opening them as a JarInputStream (this is temporary and will change later).
+
Note that there is nothing that explicitly binds together specific inputs, outputs, commands or attachments. Instead
+it’s up to the contract code to interpret the pieces inside the transaction and ensure they fit together correctly. This
+is done to maximise flexibility for the contract developer.
Transactions may sometimes need to provide a contract with data from the outside world. Examples may include stock
prices, facts about events or the statuses of legal entities (e.g. bankruptcy), and so on. The providers of such
facts are called oracles and they provide facts to the ledger by signing transactions that contain commands they
-recognise. The commands contain the fact and the signature shows agreement to that fact. Time is also modelled as
-a fact, with the signature of a special kind of oracle called a timestamping authority (TSA). A TSA signs
-a transaction if a pre-defined timestamping command in it defines a after/before time window that includes “true
-time” (i.e. GPS time as calibrated to the US Naval Observatory).
+recognise, or by creating signed attachments. The commands contain the fact and the signature shows agreement to that fact.
+Time is also modelled as a fact, with the signature of a special kind of oracle called a timestamping authority (TSA).
+A TSA signs a transaction if a pre-defined timestamping command in it defines a after/before time window that includes
+“true time” (i.e. GPS time as calibrated to the US Naval Observatory). An oracle may prefer to generate a signed
+attachment if the fact it’s creating is relatively static and may be referred to over and over again.
As the same terminology often crops up in different distributed ledger designs, let’s compare this to other
distributed ledger systems you may be familiar with. You can find more detailed design rationales for why the platform
differs from existing systems in the R3 wiki, but to summarise, the driving
diff --git a/docs/build/html/genindex.html b/docs/build/html/genindex.html
index 4ac79dca93..b8b34da994 100644
--- a/docs/build/html/genindex.html
+++ b/docs/build/html/genindex.html
@@ -87,6 +87,7 @@
Attachments are files that add context to and influence the behaviour of transactions. They are always identified by
+hash and they are public, in that they propagate through the network to wherever they are needed.
+
All attachments are zip files. Thus to upload a file to the ledger you must first wrap it into a zip (or jar) file. Then
+you can upload it by running this command from a UNIX terminal:
where DECD... is of course replaced with the hash identifier of your own attachment. Because attachments are always
+containers, you can also fetch a specific file within the attachment by appending its path, like this: