Split portal

[shimaore]

Goal: Split out code that is not API in a separate project. This includes portal, web, inbox, public, and all usercode couchapps.

Rationale:

• Most users will already have (or will build) a separate web front-end (aka provisioning system), so they'll need the APIs but not the web parts. (I made the same mistake of overbuilding the portal in ccnq2.)
• This will clearly delineate the softswitch from any surrounding pieces.
• More freedom to code tighter interfaces (esp. UI). Get rid of the inbox tyranny.

I suspect the roles piece might be able to move as well. Need to check whether voicemail and host can live without it. (Search for update:, access:, etc.)

The base API is therefor:

• CouchDB;
• the _ccnq3 API integrated with CouchDB (aka applications/couchdb_daemon);
• AMQP, eventually.

Some steps to get there:

• Rewrite any special logic that is in couchapps and which is required (e.g. to bootstrap hosts) into the API.
• Replace installation / operations pieces that currently require the portal with pieces that use the ccnq3 CLI. (Keep those to a minimum. Plus they should just be proxies for existing APIs, not implement additional logic.)
• Replace pieces that integrate with the portal (e.g. in the new voicemail API) with plugins; or with AMQP notifications. (Too bad there's no "database creation" hook in CouchDB's API, that's really all that's needed.)
• Create a separate project and move portal, inbox, web (and maybe roles, and maybe others) there. Have that project use a different config file (e.g. /etc/ccnq3/web.json).
• Also move the admin piece of the ccnq3 CLI out, and into a separate CLI tool.
• Also move all couchapps out. That means: keep the database creation stuff in, but move the usercode stuff out (except for voicemail, where the usercode is required by the voicemail application).
• The public content can move as well. (Again, make sure there isn't softswitch logic hiding in there.)
• Use the documentation to locate dependents. Search for anything that touches fields in the
  • portal,
  • web service,
  • user- (not host-) type records in the _users database,
  • the portal API,
  • the web application API, and related sections of the documentation; and move those out / rewrite with API.
• Ensure nothing is left that relies on things that were moved out. Otherwise replace with API and re-code.

[shimaore]

Also need to differentiate between "roles as provided by CouchDB" (these can still be used nonetheless) and "roles as managed in the portal", which were designed with a specific purpose (esp. account-related authorization) and should move out. For example the code in applications/roles/zappa/traces.coffee should move to the couchdb_daemon API, but its reliance on data found in the requesting user's roles is fine. (Ideally this operation should be requested via AMQP, anyway.)

[shimaore]

Done, see https://github.com/shimaore/ccnq3-web