Add emissary-specific readme

README_emissary.md

@@ -0,0 +1,75 @@
+# MakingHistory - Emissary
+
+We are customising an instance of Emissary to run MakingHistory.
+
+
+## TODO
+
+- Currently using a FILESYSTEM entry for emissary to access our MakingHistory
+  templates.
+    - Switch to using a hosted `git` repo instead
+
+
+## Brief Architecture Overview
+
+From the bottom up:
+
+- Database
+- Model Objects
+  - define info saved in database
+- Services
+  - R/W objects to db
+  - Handle queries
+  - Handle inter-object actions
+- Builders
+  - Assemble different bits of functionality from services
+    e.g.
+    access data from inbox
+    what's your username
+    is the user I'm looking at actually me
+    how many rules have I defined
+    how many people are following me
+    queries to get followers, following, folders we put people into, etc
+    i.e. info we want to collect comes from varying services;
+        builders assemble into pretty and limited API
+  - Defines the public API
+
+
+## Template Overview
+
+- templateRole
+    This role makes the template eligible to be displayed as a UI choice for user inbox
+- model
+    The model sets which go builder to use with this template
+- extends
+    Extends inherits from other templates
+- containedBy
+    Limit this template such the it can only be used from within certain others
+    NOTE: I believe templateId's would be the content of the array
+    TODO: Confirm the above note
+- schema
+    A schema sets up the data structure that will be used inside a template
+    Defines the 'data' section of relevant table entry in mongodb
+    Based on json, without linking between schemas; all rules must be defined herein
+- states
+    Each piece of content can pass through a state machine; e.g. unpublished, published, for-review, etc
+- roles
+    Works alongside states
+    [Currently being reworked in the codebase]
+    Assignable to various 'groups' [later, 'circles' as well]
+- bundles
+    Define static assets; e.g. stylesheets, js, compressed or not
+    If not defined in a bundle, we may just define a 'resources' folder,
+    whereby all content within will be fetchable by the client
+- actions
+    Every action has a name, which corresponds to a set of workflow 'steps' we
+    want to be taken when that action is called by users with a certain 'role'
+    - roles
+    - stateRoles
+        define which 'roles' can access the data when in a given 'state'
+    - steps
+        - do
+            - "view-html"
+                - by default will use the action name as the filename
+        - file
+            - define filename to be used for the step