ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-19 04:57:58 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Removed the negative reference to ethereum/bitcoin

Browse Source 
in reading this document from docs.corda.net, trying to understand the flow state machines (support /development perspective), I found that the negative outlook of limitations in ethereum and bitcoin may be a bit out-dated and interrupted learning thought/understanding - on this specific page.  adjusted the verbage to keep the point that there are development challenges that we've addressed, but removed the excess language around ethereum and bitcoin
This commit is contained in:
Lamar Thomas 2018-07-11 11:05:14 -04:00 committed by Mike Hearn
parent ac179aa9ab
commit fa92c082ba
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/source/flow-state-machines.rst
View File

@ -24,9 +24,7 @@ partially signed invalid transactions outside of the main network, and by doing
traded asset are performed atomically by the same transaction. To perform such a trade involves a multi-step flow
in which messages are passed back and forth privately between parties, checked, signed and so on.
Despite how useful these flows are, platforms such as Bitcoin and Ethereum do not assist the developer with the rather
tricky task of actually building them. That is unfortunate. There are many awkward problems in their implementation
that a good platform would take care of for you, problems like:
There are many benefits of this flow based design and some development complexities as well. Some of the development challenges include:
* Avoiding "callback hell" in which code that should ideally be sequential is turned into an unreadable mess due to the
desire to avoid using up a thread for every flow instantiation.
@ -517,4 +515,4 @@ the features we have planned:
* Being able to interact with people, either via some sort of external ticketing system, or email, or a custom UI.
For example to implement human transaction authorisations
* A standard library of flows that can be easily sub-classed by local developers in order to integrate internal
reporting logic, or anything else that might be required as part of a communications lifecycle
reporting logic, or anything else that might be required as part of a communications lifecycle