The day started with a very interesting keynote about volunteer citizen development solving problems where the government falls short.

Then I met some people of the Mailman team, Florian first, then Abhilash (for the first time), and Barry. Barry had just pushed some code in his subpolicy branch that he wanted me to review, and since I didn’t find a talk that inspired me a lot this morning, I spent a couple hours reviewing his new code and making small changes.

Afterwards I realized there were two talks I would have liked to attend, but the good thing with PyCon is that all talks are recorded, so I’ll just watch the videos later.

I had lunch with Luke and Ralph of Fedora engineering fame, and then went to a talk on Python 2 & 3 compatibility, that went over the differences and the tooling we have to overcome them. Since Mailman3 is Python 3 and HyperKitty is Python 2, there are a few intermediate libraries where knowing this will be useful.

Then I went to talks on services and concurrency, which I think will be useful in a Fedmsg-enabled Fedora infrastructure.

After the break, I went to two talks on REST APIs. HyperKitty has a REST API, and it will prove very useful for integration when it’s deployed in Fedora and elsewhere. I want to make sure the API is useful and follows best practices.

The last talk, by Jeff Schenck of chewse.com, was really interesting. With the dawn of full UI Javascript libraries like Angular.js and Backbone.js, REST APIs today are commonly used to serve data to your own application running in the client’s browser, and not to external developers only. As a consequence, an interface that used to be internal and run in a trusted environment (the server) is now callable by any web client. As a result, we need a powerful authorization models for REST API.

Permissions usually apply to table-level information (may I look at users?), column-level informations (I can look at users but may I look at user’s passwords?), row-level information (I can’t look at user’s private info except if the user is myself), and read/write permissions (I can only write my user info). And obviously a combination of all that.
Right now it’s way too complicated to implement, at least in django-rest-framework. You need to write your permissions twice: one for object listing and one for object access. Some libraries make it a bit easier but we’re far from where we should/could be.

Since I’m using django-rest-framework for HyperKitty’s API, I do intend to work with Jeff and all those interested to solve that issue.

In my very humble opinion, we should create permission classes that would utimately translate into ORM filters. This would apply nicely to object listings, and can work with single object access using another SQL request specifying the object’s primary key. For example, running this type of query: “SELECT COUNT(*) FROM the_table WHERE id=42 AND <permission-filters>”. If you get 0, you’re not allowed, if you get 1, you’re allowed. This model won’t work perfectly for read/write permissions, but they can be a bit different anyway, because they work with HTTP verbs.

Well, that’s just from the top of my head, and it my be obvious (or obviously wrong) to those who have been fighting with this for months/years.

Anyway, that was a very interesting and productive first day. Let’s see what tomorrow brings (and what I’ll be able to bring to tomorrow ;-) )

Also: Montréal is a wonderful city. It really is. And the people there are charming. Plus their language is wonderful :-D