Closed shimaore closed 11 years ago
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.)
Done, see https://github.com/shimaore/ccnq3-web
Goal: Split out code that is not API in a separate project. This includes
portal
,web
,inbox
,public
, and all usercode couchapps.Rationale:
inbox
tyranny.I suspect the
roles
piece might be able to move as well. Need to check whethervoicemail
andhost
can live without it. (Search forupdate:
,access:
, etc.)The base API is therefor:
_ccnq3
API integrated with CouchDB (akaapplications/couchdb_daemon
);Some steps to get there:
ccnq3
CLI. (Keep those to a minimum. Plus they should just be proxies for existing APIs, not implement additional logic.)portal
,inbox
,web
(and mayberoles
, and maybe others) there. Have that project use a different config file (e.g./etc/ccnq3/web.json
).admin
piece of theccnq3
CLI out, and into a separate CLI tool.public
content can move as well. (Again, make sure there isn't softswitch logic hiding in there.)_users
database,