1 files changed, 32 insertions, 0 deletions
diff --git a/docs/src/sql-map.dox b/docs/src/sql-map.dox
new file mode 100644
index 00000000000..8f288565436
--- /dev/null
+++ b/docs/src/sql-map.dox
@@ -0,0 +1,32 @@
+/*! \page sql_mapping Mapping SQL onto the WiredTiger API
+
+@todo decide whether to keep this page, if so, fill it out
+
+An RDBMS has the SQL language, a parser and a query planner.  All of them
+sit on top of WiredTiger, as they would on top of any key-value store.
+
+The difference with WiredTiger's API is that the query plan is going to be
+based on fundamental operations including:
+
+# sequential scan through a range;
+# join (various flavors);
+# sort (group by);
+# projection, and so on.
+
+Those operations would be implemented as different WiredTiger cursor types,
+using WT_CONNECTION::add_cursor_type.
+
+The cursor types could be implemented as one or more extensions, loaded
+automatically whenever the database is opened for the first time.  Then the
+cursor types would always be there, and the query planner just asks for a
+cursor that combines together data from various other cursors and comes out as
+a set of key/data pairs it can deal with.
+
+With the right set of special cursor types are implemented, one cursor could
+return the SQL result set.  That is, combining cursors would implement a
+query plan.  And that could happen over a socket, mixing local processing
+with server-side processing.
+
+This same interface could deal with many types of compression, transforming
+data on the fly in various ways (like views), and so on.
+ */