Merge lp:~wallyworld/lazr.restful/propogate-notifications into lp:lazr.restful
Proposed by
Ian Booth
Status: | Rejected |
---|---|
Rejected by: | Ian Booth |
Proposed branch: | lp:~wallyworld/lazr.restful/propogate-notifications |
Merge into: | lp:lazr.restful |
Diff against target: |
271 lines (+139/-2) 8 files modified
src/lazr/restful/NEWS.txt (+9/-0) src/lazr/restful/_resource.py (+14/-0) src/lazr/restful/example/base/configure.zcml (+7/-0) src/lazr/restful/example/base/traversal.py (+8/-0) src/lazr/restful/interfaces/_rest.py (+16/-0) src/lazr/restful/simple.py (+30/-1) src/lazr/restful/tests/test_webservice.py (+54/-0) src/lazr/restful/version.txt (+1/-1) |
To merge this branch: | bzr merge lp:~wallyworld/lazr.restful/propogate-notifications |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Leonard Richardson (community) | Disapprove | ||
Review via email: mp+54340@code.launchpad.net |
Commit message
When constructing the data object from an EntryResource to return to the client, include any informational, warning, error messages the server side call may have attached to the request.response object.
Description of the change
When constructing the data object from an EntryResource to return to the client, include any informational, warning, error messages the server side call may have attached to the request.response object.
To post a comment you must log in.
I have a couple concerns about this:
1. You're assuming that request. response. notifications exists, even though IHTTPRequest doesn't define a 'response' attribute and IHTTPResponse doesn't define a 'notifications' attribute. We already make the assumption that request.response exists, all over the place, and I'm pretty sure that's a Zope convention. So I'm not worried about that.
But where does 'notifications' come from? That's defined by INotificationsR esponse in Launchpad. We can't put Launchpad-specific code in lazr.restful, because it's used by other projects. You have a couple options:
1A: You can move INotificationsR esponse into lazr.restful, and only handle the notifications if the response can be adapted to INotificationsR esponse. You can then write a stub implementation and test the notifications code in lazr.restful. Users who have no need for this can just choose not to register an adapter from IHTTPResponse to INotificationsR esponse.
1B. You can move this code into Launchpad, and make the handling of notifications a Launchpad-specific enhancement to the lazr.restful web service. I recommend 1A instead.
2. These notifications aren't part of the description of the object, so they don't belong in its JSON representation. In the motivating case, bug 698138, the notification is "foo did not previously have any assigned bugs in barproject". That has nothing to do with the bug that was assigned. It's a notification about the *act* of setting that bug's assignee.
Just to drive this home a little more: what if a named operation has no return value, but the process of handling the request results in a notification? What if a DELETE request spawns a notification? You've got no place to set that notification. What if a named operation returns a *list* of entries and also sets some notifications? Your branch is going to give every entry a copy of the same notifications.
These notifications should be set at the _request_ level. I suggest picking an HTTP header name like X-Lazr-Notification and setting a value for that header for each notification. (On the client side, XHR should be able to handle multiple values for the same header, but I'm not sure.)
If you make this a feature of lazr.restful, you should also change lazr.restfulclient to be able to access these notifications. If you make this a feature of the Launchpad web service, you should change launchpadlib. (I'm not sure how to do this since lazr.restfulclient abstracts away the request/response cycle. Maybe notifications should just be stored in an instance-wide queue.)