Meeting Minutes for June 24, 2012


  • will be at Europython between 2nd and 8th of July, which means only partial availability for RB and will probably miss the meeting on the 8th
  • asked about the expectations for the midterm evaluation. Answer: a working prototype would be desirable
  • the current state of the action feed displays all updates on requests the user has visited, disregarding local sites
  • started looking into Ajax, in order to implement the expandable boxes (ChipX86 suggests looking into datastore.js, and adding a new web api resource; smacleod suggests following the example in
  • to properly display the local site, a local_id and a local_site fields have to be added to the Actions table
  • the current version doesn’t display the actions once a request is closed (due to deletions in the Visit table) – must investigate a solution for this
  • the text for verbs should be computed dynamically, not stored in the DB
  • the URL call to review requests performs a query to get the id and has to be fixed


  • first question is with respect to the API design, and formatters. right now, the design calls for providing a formatter (JSON decoder by default) to the client, so it can translate the responses into python dicts. what happens if someone decides no to use the default one?. ChipX86 suggests that unless there’s a really clear reason later on to add it, make it internal, and map it internally
  • should ‘Builder’ be renamed to ‘Factory’? ChipX86 and purple_cow decide to go with ‘Factory’
  • is having trouble figuring out the implementation details for wrapping the resources with the transport: how to differentiate between resource methods which contact the API and methods that don’t? ChipX86 suggests treating them the same and faking the async part
  •  right now, the design has resources having their methods return an http request, so we can wrap with the transport, and have it grab the request and execute it. How should we differentiate methods where we just pass a result out? ChipX86 says that if it’s not an httprequest, treat as data and simulate the callback.
  • another issue is related to error handling and exceptions: what should be considered an exception? ChipX86 states that exception aren’t the best idea for async, since the caller would have gotten past that code by then
  • ChipX86 mentions that the pattern we’ve used (outside Python) is to have two callbacks: one for success, one for error, both of which should be optional
  • suggests an example where they are attached with done(callback) and error(callback) after the fact is it fine to have method(done_callback=None, error_callback=None). ChipX86 agrees

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s