Changes between Version 2 and Version 3 of SummerOfCode2015

Timestamp:

Jan 27, 2015, 6:45:57 PM (10 years ago)

Author:

Russell Keith-Magee

Comment:

Beefed up discussion of URL routers; added SQLalchemy project.

SummerOfCode2015

@@ -12 +12 @@
  * Tim Graham (timograham@gmail.com) - Replace Form Media
 * Marc Tamlyn (marc.tamlyn@gmail.com) - Test framework cleanup
+* Russell Keith-Magee (russell@keith-magee.com) - Replacing middleware, SQLAlchemy / NoSQL integration
 
 == Students ==
@@ -160 +161 @@
  * Similar queries for 3rd-party backends should be added here
 
-=== Replacing middleware ===
+=== Improving URL dispatch ===
 * "Complexity:" Hard
+
+Django's URL routing infrastructure hasn't had any significant changes since it was originally introduced. As a result, there are some areas that are ripe for improvement.
 
 Django's middleware infrastructure is not particularly good. In particular the handling of exceptions is not necessarily predictable.
@@ -167 +170 @@
 It also has no way of applying itself to anything other than the entire site. With the advent of class based views, decorators are not particularly clean, and are also easily omitted. For example consider an entire reporting section which requires certain permissions - applying the permission requirement at the URLconf level reduces the chance of missing single views and leaving security vulnerabilities.
 
-A related area is providing alternatives to the regular expression based url resolvers.
+There is also a need to look at URLconfs and the URL resolution process. The current URL dispatch mechanism is hard coded, and is somewhat limited. However, if this mechanism could be customised, it would be possible to introduce new features, or even an entirely different URL dispatch mechanism, supporting features such as:
+
+ * Domain based dispatch
+ * Wrapping multiple URLs, or entire URLconfs in a decorator/middleware
+ * Alternate schemes for URL definition (e.g., a non-regex based pattern matching system)
+ * Alternate schemes for URL registration (e.g., a routing-based URL system)
+
+=== SQLAlchemy / NoSQL integration ===
+* "Complexity:" Medium
+
+With the success of the 2014 GSoC project to formalise Meta, we're now in a position to use that interface to do interesting things. 
+
+A common request over the entire life of Django has been to use Django's forms (and in particular, Django's Admin) with data stores that aren't Django's ORM. SQLAlchemy is a popular choice for those using SQL databases; a number of NoSQL data stores have also been popular at various times.
+
+The aim of this project would be to take a set of models defined in a non-Django data store, and define the mechanisms necessary to expose those models in Django's contrib.admin interface. Daniel (last year's GSOC student) proved this was possible by providing a proof-of-concept interface to Gmail inside contrib.admin.
+
+There will be two parts to this project:
+1. Developing a Django-Meta compliant interface for your non-Django data store of choice. 
+2. Fixes and improvements to Django itself as necessary to support (1)
+
+The code produced under part (1) would be a standalone repository and project, *not* a candidate for inclusion into Django itself. Django won't be gaining official SQLAlchemy support - but we will be able to point at a viable proof of concept. 
+
+This project could be taken up by several GSoC students, with each student developing a backend for a different data store. If more than one student is accepted for this project, they'd be expected to coordinate efforts on any bug fixing and/or improvements required in Django itself.