some more thoughts on modules/instances--sharing, separate servers

common/lib/xmodule/xmodule/proposal/definition.py

@@ -32,3 +32,10 @@ class XModuleDefinition(object):
         """Return a list of child locations for this definition"""
         pass
 
+    @property
+    def resources(self):
+        """
+        Return a list of static resources this definition needs.  What
+        format? type/name/path?  Perhaps just Locations, with category
+        'js', 'css', 'image', etc?  Then would be included in child_locations...
+        """

doc/instance-proposal.md

@@ -33,20 +33,40 @@ An instance is uniquely identified by "org/course/run/instance_id".  Since insta
 
 * User chooses a definition, gets an instance of it, with some default instance id ('category/url_name', perhaps).  Can customize parameters, put it somewhere in the course, etc.  All the magic happens behind the scenes.
 
+* Can import e.g. problems from other courses.  A problem may itself include a variety of static resources (images, code, js+css, etc), but since we're planning on having the definition db be shared, these should be accessible from any clone.  We do need a pipeline-style hash-based versioning system for static files too, so that e.g. images don't change underneath users.
+
+* Not thought through as well: interaction of sharing and modifications.  Clone?  Pull request?  When my problem A has been cloned, and I then change it, does the clone also update?  Configurable?  (e.g. problem@hash, problem@HEAD, problem@FredsBranch.  I kind of like the idea of using git-style hashes instead of increments--doesn't try to assign a linear order to what will be a non-linear tree).  Also will likely want notifications, etc.  I think that working out the full details can be safely postponed for a few months--we just need to allow multiple use and cloning for now.
+
 ### XML integration
 
 * file format/layout -- can support existing (new) format, interpret 'category/url_name' as the instance_id for everything by default.
-* Can enable reuse of definitions, by separating out instance_ids from url_names.  So a pointer tag would become
-  <category url_name='this_is_the_definition_pointer' instance_id='this_is_the_id'/>
+* Can enable reuse of definitions, by separating out instance_ids from url_names.  So a pointer tag with an explicitly specified instance_id would be
 
+    <category url_name='this_is_the_definition_pointer' instance_id='this_is_the_id'/>
 
 ### Modularity support....
 
 * This set of changes doesn't have a big effect on our ability to put various things on different servers.  We should still be able to implement:
-    * Definitions can live in various different places (e.g. partitioned by org or course)
+    * Definitions can live in various different places (e.g. partitioned by org or course).
     * We can (and should) design an service API that would let us run individual module code in separate processes/servers, and sandbox as necessary.
 
-* The required_capabilities flag may allow us to pass less stuff to modules that don't need extra things.  Since I think the current plan is that edX folks will be the only ones to write container modules for now, this means that we can lock down the access modules get.
+* The required_capabilities flag may allow us to pass less stuff to modules that don't need extra things.  Since I think the current plan is that edX folks will be the only ones to write container modules for now, this means that we can lock down the access modules get.  (Details?)
+
+### Access control
+
+* I'm still hoping to keep the modules from having to know about access control, different types of users, etc.  This may be wishful thinking -- we're already passing in things like "is_staff" to change what information is displayed.
+
+* We'll need to sort out access control for the ModuleService API too...
+
+### Sketch of an externally contributed module:
+
+* They define some definition format (xml/json/whatever)
+* write definition class
+* write instance class
+* write module class
+* if they're hosting their own module service, run a server that can do "module math": "definition + parameter -> instance", "instance + student state -> module", and then all the module stuff.
+
+* Deployment note: if we're going to have different groups running their own module services, we need to think about how we're going to keep the xmodule library versions synced.  Step one would be having everything be versioned, and exposing that version through APIs.
 
 
 
@@ -59,3 +79,9 @@ An instance is uniquely identified by "org/course/run/instance_id".  Since insta
 ## Design plan:
 
 * I've been finding myself adding convenience methods to the XModule and XModuleDefinition interfaces over the last few months (e.g. get_child_by_url_name, compute_inherited_metadata).  It may be better to keep the core interface small, and add those to a separate util class.
+
+## TODO:
+
+* Design API for ModuleService (draft in basecamp from a few months ago)
+* Figure out plan for security
+* Is there something special we need to do for definitions that reference static resources?  Ideally we don't just have links embedded in the def in a way the system doesn't understand.