From fa92c082badf0e6e50e1ed78232d36d313c4582a Mon Sep 17 00:00:00 2001 From: Lamar Thomas <38670842+r3ltsupport@users.noreply.github.com> Date: Wed, 11 Jul 2018 11:05:14 -0400 Subject: [PATCH] Removed the negative reference to ethereum/bitcoin 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 --- docs/source/flow-state-machines.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/source/flow-state-machines.rst b/docs/source/flow-state-machines.rst index 5f7f2a8caa..c48481df3c 100644 --- a/docs/source/flow-state-machines.rst +++ b/docs/source/flow-state-machines.rst @@ -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 \ No newline at end of file + reporting logic, or anything else that might be required as part of a communications lifecycle