Notes from the afternoon so far.

dayTwo-embedding/notes.md

@@ -0,0 +1,35 @@
+Embedding
+---------
+
+  - CouchDB's replicator makes it ideal for embedding it onto different
+    platforms (ex., mobile), but it's developed as a server (ex., MySQL) which
+    does not allow for this very easily.
+
+  - See SLEEP spec and comments from yesterday.
+
+  - The ideal would be to pull out the core storage engine and use it like
+    bitcask, allowing for easy and direct integration into erlang apps via
+    erlang calls.
+
+  - One of the big wins for CouchDB to do this is that more erlang people will
+    be using our code and therefore (hopefully) contribute more code to us.
+
+  - Rebar is may or may not work for us.
+
+    - We need to figure out what the list is of things that autotools gives us.
+
+    - Autotools makes it very easy for cross platform compile.
+
+  - We don't necessarily need to change our build system. We can make it so
+    that you can import our code into something like rebar.
+
+  - We also need a clear, well documented erlang interface.
+
+**The Results**
+
+  - We're not interested in making the current CouchDB implementation
+    embeddable onto other platforms like mobile. The answer to the is, and has
+    been historically, re-implementations of protocols (ex., PouchDB).
+
+  - We're going to create a clear and documented erlang interface for erlang
+    developers to interface directly with the persistence engine.

dayTwo-security/notes.md

@@ -0,0 +1,39 @@
+Security
+--------
+
+  - Punt to third parties anything that isn't isAdmin?
+
+  - Core is responsible for authorization, plugins can be responsible for
+    authentication.
+
+  - We're not a web framework.
+
+  - Provide a clear mapping to plug the other authentication services into
+    couch.
+
+  - Basic and Cookie authentication are the only things we want to support in
+    core/distrib.
+
+  - Add the concept of where you're coming in from (localhost vs lan vs wan)
+    and use it for authentication: even if you have the right creds, you won't
+    be able to do admin things by default.
+
+  - Have a fine grained matrix of privs per user. Ex., can compact, call
+    /_restart, etc.
+
+  - Move the _users database behind an API.
+
+  - Side note, want per db configs (might consume _security)
+
+  - We need to add on accounting/auditing (ex., sudo log).
+
+  - Do we want to go with a global authentication system? NOT REINVENTING, but
+    use something that's pre-existing.
+
+**The Results**
+
+  - We need to start from highly locked down and then increase the surface
+    area over time or via config. (Analogies about trains, mathematics, etc.)
+
+  - We will consider distributed identity, but it could also be added via
+    plugins.

dayTwo-weightLoss/notes.md

@@ -0,0 +1,45 @@
+Weight Loss: What to Remove
+---------------------------
+
+  - One of the replicator end points.
+
+    - Keep the new API (_replicator) and have it support one off replications
+      (ie., self terminating db).
+
+    - Or keep _replicate, providing something like ?ephemeral, and nuke
+      _replicator. Has the benefit that we're not changing the default behavior
+      of databases (self deleting docs).
+
+  - all_or_nothing
+
+  - _restart
+
+  - _sleep
+
+  - How long to keep old revs?
+
+  - total_rows and offset fields in view results
+
+  - temporary views
+
+  - rotate view in and out (ie., production views can't be hit if they don't
+    have an index on disk), requiring dev/pre-production views to be warmed by
+    the server
+
+[incomplete, need to look at Joan's notes for the rest]
+
+**The Results**
+
+  - Delete:
+
+    - all_or_nothing
+
+    - Use the old API, _replicate, instead of the new API, _replicator.
+
+    - _restart
+
+    - _sleep
+
+    - temporary views (do them in browser)
+
+[incomplete, need to look at Joan's notes for the rest]