Labs/Weave/PythonMigration

Reasons for Migration

1. The trend in operational support towards Python installations, provides us with better infrastructure knowledge, problem response, and shareable tools.
2. We now have much greater in-house Python expertise than PHP. Many of our recent hires have been high-profile figures in the Python community. This will lead to higher quality of code, but also higher quality of reviews.
3. The current PHP codebase was originally written to support a model that has been refined extensively since it was first written. We can leverage this knowledge to write a cleaner server that will be easier to mdoify going forward.
4. It seems that the transition is inevitable at some point, and this transition will be more painful the longer we wait.

Pitfalls

1. The current code is tested and functional. We can mitigate this with an extensive testing suite (which already exists) as well as the more extensive use of unit testing that Python supports.
2. External users with current installations will suffer some migration pain. Much of it we can mitigate, and the underlying storage isn't changing, but some systems may not offer Python as an option.

Requirements

P1

1. Implementation of documented Sync API, sufficient to pass the full suite of tests
2. Implementation of documented User API, sufficient to pass the full suite of tests
3. Unit tests on every class
4. Fully functional memcache support for collection counts, timestamps and tabs
5. CEF implementation
6. Correct unicode handling for all user contact points
7. Webpages for resetting password and deleting account (decoupled from API codebase)
8. Support for storage quotas

P2

1. User API server capable of handling internal and external interface with config change
2. functional no-config server tarball (Weave Minimal, including SQLite support)
3. account lockout support
4. Constant-independent storage engines (so you can instantiate multiples of a class)
5. Standard VM instance with full dev environment that supports all our options

P3

1. Support for non-mozilla LDAP setups, and mysql setups not using a userid
2. shell-script setup
3. support for rate quotas