Feature request: online KA Lite

[bcipolli]

Use cases:

• Schools: When online access is possible / preferred for some members of a group, and not available to others, but all must share the same KA platform (a la HTH). Accessing online can be much more convenient for those who can do so (no need to install, no need to physically transport anything from home)
• Prisons: When someone starts learning on KA Lite offline, then is released with their data. Online access would allow them to continue learning at a public library, for example.

This may be a blocking issue for HTH deployment.

Issues and suggested implementations:

• Streaming would be expensive; however, requests for videos could be redirected (302) to amazon aws?
• Online installation would have to sync multiple zones worth of data with the central server.

[bcipolli]

@rtibbles here's how we do this:

• We create a special "superzone" zone that downloads data from all zones.
• We add code to the central server side such that, if the recipient device is on the "superzone", group names have org / zone / group compressed into a parseable string
• We add code to the distributed server side to parse these names and, if org/zone information available, we present these drop-downs in the login page, along with the "group" dropdown.

So, we should be able to do this with less than 50 lines of code. I say we do it! :D

@jamalex any thoughts?

[bcipolli]

I am still a huge fan of this idea. To solve the "sharing networks" issue (how to select your zone??), we could:

• Have a separate URL for each organization, that admins can access from their org admin page. Then only facilities from "sharing networks" within that org would appear in the login dropdown
• Similar idea, but per-sharing network.

http://kalite.learningequality.org/online/ - homepage http://kalite.learningequality.org/online/login/ - login page with EVERY facility for EVERY sharing network http://kalite.learningequality.org/online/login/org_id/ - login page with facilities for every sharing network within an org http://kalite.learningequality.org/online/login/org_id/zone_id/ - login page with facilities for a single sharing network

[bcipolli]

Two ways I can see this being implemented:

1. Through a distributed server that is "trusted" by the central server.

Issues:

• would require special code to rewrite signing and zone information, such that after data is synced to the central server (from the online 'trusted' distributed server), it is signed by the central server and has a fallback_zone of the facility of the user that created the data.
• would require manually marking the device as trusted, both on the central server and on the distributed server
• would require app-wide verification that "is_trusted" is not assumed to mean "is_central_server"
  1. By creating a special zone (either with a special ID, or with a special name; either way, the zone must be signed by the central server), then adding logic to the in_zone procedure such that all models return True if the model was last saved by a device on the special zone, or if the comparison zone is the special zone.

Issues:

• data updated on the special zone (on the KA Lite online website) wouldn't be synced to devices of older versions (that wouldn't recognize data from that special zone to be on their own).

I'm playing around with this second option, to see how much added complexity this causes. Right now, I believe this can be done with only 8 lines of code being changed.

[bcipolli]

Hmm, getting complicated. Option 3:

• central server LIES to all distributed servers, and tells them that devices it sees are on the SUPERZONE, are actually on the zone that the device is on. This should even work for P2P sync, at least in the case where syncing was still only within zone. But it's dangerous--there would be conflicting DeviceZone objects out there, which in the long-term (or short-term) could cause problems.

[rtibbles]

This is off our roadmap now. Won't fix.

[jamalex]

This one I think would be good to leave open as a Nice to Have, since I can imagine quite a few use cases. It will only be feasible to implement it once we've got better DB-specific URL namespacing (0.15?), so it's a ways off.

And actually, once we've got things to a more namespaced... space... this approach could actually make things easier. It means we don't have to have as much divergence between the central and distributed servers; the central server could consist of:

1. an entry portal
2. a place to manage organizations
3. a place to register DBs to organizations
4. some tools for aggregate reporting/data export across multiple DBs within an org
5. separately-mounted distributed server URL entry point for every DB, where you can engage with every feature that's in the distributed server (content, user administration, coach reports, etc), the exact same way you would if logged into the distributed server

I see quite a few advantages to this:

• We wouldn't need to deal with the headaches of making sure distributed server features integrate cleanly into the central server, since we would basically just be running the same thing on the Hub (could even have (5) launch in a new tab, with styling identical to distributed server)
• We wouldn't need to maintain as much parallel documentation for the central server, if most things were done exactly the same way as on the distributed server. Users (of all types) could also more easily transition between distributed and central server, with a familiar user interface and navigation.
• It should be easier to manage a unified permissions system this way.
• By default, you would need to know the DB UUID in order to get to the login page (thus helping to limit exposure). But we could have a central server org admin feature where you set up a nice readable URL slug alias that would redirect to the login page for that DB.

Some challenges (but things we'd probably need to deal with in some form anyway):

• What channels do these central server versions of the distributed server subscribe to? Maybe just all channels?? And more generally: How do we handle coach reports for usage data from a channel the current installation isn't subscribed to?

[mjptak]

Sounds like a great place for people to share/build community with things like exercises (Perseus or otherwise)...think about it....Portuguese exercises translated into English...not only the other way around. Lots of possibilities but having witnessed things like the Google/Trimble 3d warehouse grow and flourish in the ecosystem of an even sort of open source community I am hopeful.

On Sat, Mar 21, 2015 at 12:10 PM, Jamie Alexandre notifications@github.com wrote:

This one I think would be good to leave open as a Nice to Have, since I can imagine quite a few use cases. It will only be feasible to implement it once we've got better DB-specific URL namespacing (0.15?), so it's a ways off.

And actually, once we've got things to a more namespaced... space... this approach could actually make things easier. It means we don't have to have as much divergence between the central and distributed servers; the central server could consist of:

1. an entry portal
2. a place to manage organizations
3. a place to register DBs to organizations
4. some tools for aggregate reporting/data export across multiple DBs within an org
5. separately-mounted distributed server URL entry point for every DB, where you can engage with every feature that's in the distributed server (content, user administration, coach reports, etc), the exact same way you would if logged into the distributed server

I see quite a few advantages to this:

• We wouldn't need to deal with the headaches of making sure distributed server features integrate cleanly into the central server, since we would basically just be running the same thing on the Hub (could even have (5) launch in a new tab, with styling identical to distributed server)
• We wouldn't need to maintain as much parallel documentation for the central server, if most things were done exactly the same way as on the distributed server. Users (of all types) could also more easily transition between distributed and central server, with a familiar user interface and navigation.
• It should be easier to manage a unified permissions system this way.
• By default, you would need to know the DB UUID in order to get to the login page (thus helping to limit exposure). But we could have a central server org admin feature where you set up a nice readable URL slug alias that would redirect to the login page for that DB.

Some challenges (but things we'd probably need to deal with in some form anyway):

• What channels do these central server versions of the distributed server subscribe to? Maybe just all channels?? And more generally: How do we handle coach reports for usage data from a channel the current installation isn't subscribed to?

— Reply to this email directly or view it on GitHub https://github.com/learningequality/ka-lite/issues/134#issuecomment-84394193 .

[benjaoming]

Closing this issue so it doesn't advertise a false promise of a kind.

Of course, the initial motivation should be food for thought for the new Kolibri project: http://github.com/learningequality/kolibri