@@ -34,7 +34,7 @@ Unfortunately, due to the quirks of legacy implementations, much of what develop
3434
3535## Chris Date's Contribution
3636
37−Chris Date is a prolific author, researcher, and lecturer on relation algebra and database design in general. Project:M36 would not exist without his writings on the mathematical underpinnings of the relational algebra. Project:M36 does not however implement all Date's recommendations. In particular, Project:M36 implements:
37+Chris Date is a prolific author, researcher, and lecturer on the relational algebra and database design in general. Project:M36 would not exist without his writings on the mathematical underpinnings of the relational algebra. Project:M36 does not however implement all Date's recommendations. In particular, Project:M36 implements:
3838
3939* **algebraic data types** inspired by Haskell's types in lieu of Date's convoluted data types based on object-oriented type systems
4040* **transactions in a graph** in lieu of Date's temporal constructs
@@ -55,7 +55,7 @@ Project:M36 implements multiple interfaces:
5555
5656### Real Estate Database Example
5757
58−To understand how Project:M36 stacks up against the fictional programming language shown in the paper, we have implemented the [example from the paper](examples/out_of_the_tarpit.tutd). The language used in the script is a dialect of Chris Date's TutorialD language.
58+To understand how Project:M36 stacks up against the fictional programming language shown in the paper, we have implemented the [example from the paper](/examples/out_of_the_tarpit.tutd). The language used in the script is a dialect of Chris Date's TutorialD language.
5959
6060### Feeders and Observers
6161
@@ -63,15 +63,15 @@ The "Out of the Tarpit" paper distinguishes between pushing data to the database
6363
6464SQL developers are already intimately familiar with "feeders"- these are merely INSERT and UPDATE statements issues to the database via some middleware.
6565
66−However, most database do not support and adequate notion of observers. The purpose of an observer is to notify interested parties about relevant changes to the state of the database so that clients relying on the database are viewing the most "up-to-date" information from the database. Project:M36 implements this requirement by allowing clients to register relational expressions by name and return relational expression. When the result of the relational expression changes in a tracked state (branch) of the database, an asynchronous notification including the name and the result of return relational expression is sent to the client. The client can then use this information to update its own user interface or take further automated actions.
66+However, most database do not support an adequate notion of observers. The purpose of an observer is to notify interested parties about relevant changes to the state of the database so that clients relying on the database are viewing the most "up-to-date" information from the database. Project:M36 implements this requirement by allowing clients to register trigger relational expressions and return relational expressions. When the result of the relational expression changes in a tracked state (branch) of the database, an asynchronous notification including the name and the result of return relational expression is sent to the client. The client can then use this information to update its own user interface or take further automated actions.
6767
6868Some SQL databases include a similar feature; in PostgreSQL, this is activated by [LISTEN](http://www.postgresql.org/docs/9.0/static/sql-listen.html)/[NOTIFY](http://www.postgresql.org/docs/9.0/static/sql-notify.html). However, PostgreSQL offers no provision for triggering notifications based on the state of the database- this crucial feature is left to the database developer. Furthermore, the return payload can only be a string, not the result of a relational expression evaluation.
6969
7070## Good Riddance to Old Baggage
7171
72−Project:M36 is a clean-room implementation of a relational algebra engine; it does not implement SQL or any other legacy standard. While this means that Project:M36 is incompatible with other RDBMS, it means that Project:M36 can avoid the substantial pitfalls of previous implementations, such as:
72+Project:M36 is a clean-room implementation of a relational algebra engine; it does not implement SQL or any other legacy standard. While this means that Project:M36 is incompatible with other RDBMSs, it means that Project:M36 can avoid the substantial pitfalls of previous implementations, such as:
7373
74−* [three-valued logic (NULL)](docs/on_null.markdown)
74+* [three-valued logic (NULL)](/docs/on_null.markdown)
7575* non-relational database constructs such as row and column ordering or OUTER JOINs
7676* linear transaction flow and conflict resolution
7777* direct table-to-file mapping which create perverse model-data dependencies
@@ -83,8 +83,9 @@ Project:M36 is a clean-room implementation of a relational algebra engine; it do
8383
8484Project:M36 is just getting started as an ambitious open-source project- please join us! Immediate future features include:
8585
86−* transaction graph branch merging (never bother with "master-to-master" conflicts again)
86+* transaction graph branch merging
8787* making maximum use of parallelization
88+* decentralized databases (like git source control)
8889* static and statistics-based optimizations
8990* multiple, simultaneous storage representations for relations
9091* more network access methods, including a WebSocket driver
@@ -92,4 +93,4 @@ Project:M36 is just getting started as an ambitious open-source project- please
9293
9394## Try It!
9495
95−To learn more about Project:M36, try the [15 minute tutorial](docs/15_minute_tutorial.markdown).
96+To learn more about Project:M36, try the [15 minute tutorial](/docs/15_minute_tutorial.markdown).