status-im
/
status-react
mirror of https://github.com/status-im/status-react.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Remove jail + Status.js API 

Signed-off-by: jhe <jan.herich@gmail.com>
This commit is contained in:
jhe 2018-08-16 11:29:20 +02:00
parent 43263a9abe
commit 854acebb70
No known key found for this signature in database
GPG Key ID: 75A22903170BB4AA
1 changed files with 51 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
doc/decisions/0010-remove-jail-and-status-api.md Normal file
View File

@ -0,0 +1,51 @@
# 0010. Remove jail and Status API
| Date | Tags |
|---|---|
| Thu Aug 16 | jail, 3rd-party-code, extensions |
## Status
accepted
## Context
Originally, we supported 3rd party status extensions in form of javascript jailed execution environment (eq Jail) + small js library exposing chat commands API to js code.
While neat in theory, it has some serious downsides:
- Design of the API was quite poor, preferring mutable semantics over stateless API leveraging strength of the host application (cljs/re-frame).
As a result of that, more dynamic/state requiring things (like the live tx detail in `/send` command messages) were very hard to do,
so instead of "eating our own dogfood", we decided to side-step the API and implement such things as hard-coded logic in the app, while partly
retaining the js code for "easier" things (like parameter declaration).
Needles to say, such efforts produced code of very poor quality, riddling our app with hard-coded "magic" everywhere in the codebase, completly
defeating the point of "dogfooding" while still requiring more effort and being much more error prone (no way to unit test jail logic) because
of the need to asynchronously communicate with jail for leftover logic in command messages (the parts not hardcoded in app).
- We were in a state where there was not even one command defined completely in jail, with all of them requiring custom hardcoded logic in app to
actually work.
Due to numerous changes and rush to get things working, half of the API was obsolete and was not working/working differently then described in
the API documentation.
- We are quite tight stretched regarding performance and the Jail didn't particularly help with that - whenever some command message was defined in
Jail, it required constant RN Bridge "ping-pong" whenever sending the message or receiving the message, eating more resources + breaking otherwise
quite simple logic into harder to reason asynchronous call chains (execute method defined in Jail, wait for the result, execute next method in Jail...).
- Till now, there was no real interest in 3rd party bots anyway - the only "real" DAPPs submitted to status were "normal" DAPPs utilising just the `web3.js`
API and built on top of regular web technologies, so they could be ran in any Ethereum client like Metamask or Mist, besides Status.
- There is a very promising new concept of extensions (project pluto), which will enable to extend status with much nicer and declarative extension
definitions.
Such extensions will not be able to only hook-in into the command messages logic, but also other application (host) hooks, like wallet assets/collectibles,
chat contacts, etc.
## Decision
In the light of points above, we decided to remove Jail and `Status.js` API from the application and re-work command messages in set of nicely
encapsulated app level protocols, so command related logic will be defined in one place, commands will be able to leverage strength of our platform
and development of any new functionality related to them will be much faster and more pleasant.
We will address the 3rd party code issue separately by extensions.
## Consequences
`Status.js` is deprecated and there is no way to define custom commands using javascript only.