learningequality/ka-lite — pull request #502 by bcipolli (2013-08-17 22:28:08+00:00)
Title: Securesync sub-modules

This addresses #500. It was really helpful to separate securesync into 3 sub-modules of varying inter-dependence:
* users - "what" - deals with the data that are synced: Facilities, FacilityGroups, and FacilityUsers. Mostly about logging in/out, adding, etc.
* devices - "who": deals with the interaction between devices. Things like defining a device, a zone of trust, and which devices belong to which zones.
* engine - "how": this is how the syncing happens. Includes the methods for syncing, saving, establishing sync sessions, etc.

Along the way, the following changes were made:
* A bit of cruft was removed (unnecessary imports, two "crypto_login" functions that weren't used)
* ROOT_UUID_NAMESPACE definition was moved into settings (and made overridable in local_settings)
*

Along the way, the following HACKS were implemented:
* There was one place where interdependence between sub-modules caused import problems: between `securesync.devices.models` and `securesync.engine.models`--specifically the interaction between the Device model and the super class `SyncedModel`. The design itself is a little weird--`Device` is derived from `SyncedModel`, ... yet the base class uses that `Device`!

I found a way to dynamically import the Device model when needed (on the fly), to avoid that issue. This seemed fine to me, as again--the classes themselves are a bit odd (though in a way that makes sense).

* In order to define models outside of their regular places, and still be in the `securesync.models` namespace (see #500 for why I wanted to do this), I had to define the `app_name` property on the `Meta` class for each object. This property, unfortunately, is inherited in subclasses. That means that all sub-classes of `SyncedModel` now appear in the `securesync` class.

In order to work around this, each subclass of `SyncedModel` that is NOT in the `securesync` module had to define an empty `Meta` class, to clear that property. Yuck.

I believe the need for this may would disappear when we're able to scrub the imports. It's not the worst workaround known, but it's less than ideal.