Motto: "Automation literacy for all peoples."
build [event-driven] software you never thought possible
Drastically simplifying event-driven programming with a lightweight module: easy-to-use JavaScript Object Notation with Function Objects included.
The structure of JSON. The functionality of JavaScript. A bridge between stateless (halted) and stateful (non-halting) objects.
This site is still under development. Please visit again soon for an improved experience. Or, sign up to our newsletter for updates. Thanks!
Jump to: EXAMPLES | TEAM | LINKS
Hi, the SeedTree DB founder here.
Event-driven programming is an incredibly powerful and extremely popular GUI and Web app software paradigm: well over 90% of all websites use JavaScript and JavaScript is event-driven. If an app is user controlled (has a UI) or communicates on the Web (uses APIs), it probably relies on event-driven scripts.
However, event-driven development comes with major downsides. As Wikipedia puts it: "the event-action model leads programmers to create error-prone, difficult to extend and excessively complex application code."
A few years ago, I made my first sophisticated event-driven program. It was an interactive e-contract Web app with jQuery to handle UI and REST events. I stopped working on the program when it became so complex, it was error-prone and difficult to extend. It became complex because it lacked unified hierarchical structure.
I couldn't make another program like that. There had to be a better way! After years of first principles R&D, I've come up with SeedTree DB as the solution.
SeedTree DB is a JavaScript add-on with a very small footprint that lets programmers adopt JSON-like tree structure within a program whenever they want.
=> SeedTree DB scripts are JavaScript Object Notation files/modules with working Function Objects; JSON document stores are JavaScript Object Notation files without Function Objects (unless stringified).
We're in the process of conducting research to empirically show how much SeedTree DB lowers complexity and improves efficiency compared to the alternatives.
In my experience, SeedTree DB drastically lowers complexity by giving each function the regiment necessary to fit into distributed-state compilations with simplicity and ease. As such, my SeedTree DBs don't have definition scope issues or control flow timing issues. Apps are fast to extend with very few and quick-to-fix errors to debug.
With SeedTree DB, I've been able to build parallel, multithreaded event-driven order on top of order sans namespace collisions or problematic unmet promises/callbacks, far beyond what I was able to do without its graceful constraints.
As soon as possible, we'll open up sliding scale subscriber Git repositories so you can start using this groundbreaking proprietary technology in your projects. The repositories will include working modules that you can use as-is or as templates to get you started.
** To sign up to our newsletter, please click here. **
Why is it that SeedTree DB is the first to develop something as fundamental as script/database hybridization?
=> Scripts define change whereas databases define order. We had to reimagine "irrational" number theory to find a way to harmoniously marry these two "opposing" concepts as one before we could properly visualize SeedTree DB.
Please visit this GitHub repository for an example of the grammar SeedTree DB uses. Though SeedTree DB was removed from this repository at publication, SeedTree DB scaffolded the code flow during construction.
These examples are of the runtimes, not the scripts. Runtimes and scripts reflect each other. The scripts are easy to make. We'll have script demos ready soon.
If you want, you can expand the following videos full-screen as well as pause on specific frames. Each video is at or under 1 minute long. Click here for a playlist with additional and real-world demo videos, including a Twilio/Raspberry-Pi e-ink programmable SMS pager example.
(1) In the above example, we show the "x" tree-app and its children. Then we show the "x.tool" branch and its children. We show how the "x.tool.example" branch applies its schema and gives the user feedback about an input value that conflicts with its schema. Finally, we show a successful "x.tool.example" branch input. Note how each "x.tool.example" output is recorded as a greater than zero "$#" child leaf object in the "x.tool.example" namespace stack.
(2) In the above example, we attempt to add a data object input to the "x.tool.example.$2" database leaf. The database successfully adds one of the data object input's key/values to a matching key/null leaf-destination cell in the database. The database refuses the other data object input's key/value because the key/value leaf-destination cell is already occupied in the database.
(3) In the above example, we try to add a key/value without a preexisting key leaf-destination in the "x.tool.example.$2" database leaf. The database gives us feedback about our error. We respond by trying again with an 'o' option that overrides the default requirement that an entry can only be added to the database if the database already has an empty key/null cell available. We then try the previous example's key/value with an already occupied "x.tool.example.$2" key/value leaf-destination but use an 'n' option that overwrites the already occupied leaf-destination's cell-value.
(4) In the above example, we make a successful "x.tool.example" branch input. After that, we lookup the output by entering its "x.tool.example.$3" leaf address. We try to do the same for "x.tool.example.$4" but, since the 4th "x.tool.example" output hasn't happened yet, the database returns no leaf. We try it for the "x.tool.example.$2" output, which has happened, and the database returns the leaf. We then lookup the "x.tool.example" branch and observe its "x.tool.example.x" key/value. We change its "x.tool.example.x" value to a different value. Finally, we make a schema-successful "x.tool.example" branch input and "x.tool.example" uses the new "x.tool.example.x" value to calculate its "x.tool.example.$4" output object.
(5) In the above example, the "x.twil" progammable-database branch is a GET server calibrated for Twilio Programmable SMS Webhooks. When Twilio contacts the branch with an SMS, the branch's "x.twil.chat" child determines the SMS is a number and then, using the "x" namespace, sends it to the "x.tool.example" branch. "x.tool.example" processes the SMS input like any other input: applying its schema and additional calculations, then recording the output as the next "$#" child leaf object data entry in its stack.
(6) In the above example, we look up the "x.tool.example.$0" metadata-header value determined by the database's kernel-module. We then change the "x.tool.example.$0.show" database metadata-header setting to on. After that, we try an input improper for the "x.tool.example" schema and the database gives us feedback about it. Finally, we lookup "x.tool.example" and see that, now with the show setting turned on, the "x.tool.example.$6" output we just made with our failed input attempt is visible in the "x.tool.example" namespace.
(7) In the above example, we lookup the "x.tool.example" namespace constructor function, the namespace constructor function for each of the greater than zero "x.tool.example.$#" child leaf output objects of "x.tool.example" and, finally, the instructions "x.tool.example" uses to calculate the values of its greater than zero "x.tool.example.$#" child leaf output objects.
(∞) In the below example, a walkthrough of the above (1) to (7) examples.
** To sign up to our newsletter, please click here. **
Kyle MacLean Smith B.B.A., J.D.
Founder & Inventor
Victoria, BC, Canada
For more about me, please visit my personal website linked directly below.
besta.pe
Facebook + Instagram + Twitter + YouTube
Motto: "Automation literacy for all peoples."
