Updated Getting to 1.0 (markdown)

Getting-to-1.0.md

@@ -14,7 +14,7 @@ Stuff that needs to change
   + Becomes a type of standard Django Template Response, with `.render()` method.
   + `add_header()` dropped from `View` - set headers on the response as with standard Django.
 3. Request to extend from `HttpRequest`.
-  + `self.DATA`, `self.FILES`, `self.auth`, `self.method` will become `request.DATA`, `request.FILES`, `request.method`...
+  + `self.DATA`, `self.FILES`, `self.auth`, `self.method` will become `request.DATA`, `request.FILES`, `request.method`...  Regular attributes on the request (eg. `.META` etc.. will still be available)
 4. `Resource.filter_response`, `Resource.validate_request` -> `Serializer.serialize`, `Deserializer.deserialize`
   + `Serializer`, `Deserializer` will be decoupled from `Resource`.
   + Method names changed to `serialize`, `deserializer` - conceptually more obvious.
@@ -38,6 +38,7 @@ Stuff that might not be quite perfect, but will do for now
 
 1. `.get_bound_form` will be on the Deserializer.  Not perfect, and I think there might one day be something like a deserializer/renderer that handles form generation, but it's too tricky to tackle right now, and I don't think it's worth it.
 2. Still not sure if having View.resource, View.serializer, View.renderer etc... be classes rather than instances is necessarily the best way around.  Possibly too complicated to figure out until the basics are throughly sorted out.  Also, it does work OK at the moment.
+3. Having the view instance passed to all the pluggable components is a bit hacky really, and it'd be nice to get rid of this.  That won't be able to happen until the Request (3) and Response (4) changes above have happened, and even then it's still a bit tricky (eg the Documenting Renderers need to know the view name and description.)  May happen before 1.0, may happen after.
 
 Stuff that's not quite figured out
 ==================================