Roadmap

This is a draft of a roadmap to 1.0 for django-browserid.

Stuff we want before 1.0

Simplify the API to revolve around subclassing.

The Verify view is powerful because it is class-based, and users can easily customize a small portion of our functionality by creating a subclass and substituting it in. The authentication backend is similarly customizable.

I think this could extend to things like the verify function; if we had a Verifier class, users who wanted to use a service besides Persona for remote verification could subclass and customize it. Later one, we could add in local verification with another class that implements the same API.

This would also help us reduce our reliance on settings, which makes testing and some internal code messier to work with.

Add tests for the JavaScript code to the test suite

Implies that we make the JavaScript code a bit more testable, as well.

Officially support Python 3

It's the future! At a minimum this means Python 3.3.

Add support for BrowserID in the Admin Interface

This would help get rid of issues with the admin interface logins behaving odd on the main site, and makes logging into the Django admin more pleasant.

Use AJAX to submit the assertion to the server instead of a <form>

This will enable login flows that don't involve a page refresh without a lot of customization.

Remove the need for {% browserid_info %} at all

Along with removing the form tag above, it would be nice to somehow get rid of the need to add browserid_info to page templates, as it is easily forgotten and kinda hacky. Perhaps a middleware that adds a JS-accessible cookie?

Refactor all tests to be class-based

For consistency's sake.

Use tox for local testing

tox will let us test in many environments locally, and is a good compliment to testing PRs on TravisCI.

Clean up documentation

The documentation could use a bit of cleanup. Specifically, one area we could improve would be to replace the "Advanced" catchall to something more like the Further Examples section from the Mock docs.

We should have people go through the docs and give feedback on their pain points and what was really good about them.

Things we might want before 1.0

Do something better than mock_browserid

I'm not convinced it's the best way to auth users for tests.

Drop support for Django 1.3

1.6 is in beta, and there's some code lying around that could be removed if we dropped 1.3 support. I'm comfortable with committing to support for the current Django and the last minor release, possibly even the last 2 minor releases, but anything more than that is silly.

Integrate with PyBrowserID

There's been an issue for this for a long time, and our verification code hasn't changed much in a long time, which suggests that there's not much functionality needed here. Bonus points, this lets us have local verification immediately.

Will have to check with @ametaireau what the story is on maintenance of that library.