"Service apps"

[stuartpb]

So yeah, this has to be permissible: as an alternative to repo-based apps, it should be possible to instantiate a service as an app (primarily for CouchDB, but also for other apps-distributed-as-a-service).

There are a few reasons this goes in the app namespace, but the primary one is that they share the same namespace in terms of domains etc, so it's simpler to think of all "standalone services" as apps. (It also makes it a cinch to consider apps as services.)

It also means apps have to be interlinkable. Also, service definitions should change to be templated, with a default for the name of the service's name (so I could have "USERS_RDB_IP" and "POSTS_RDB_IP" or something for the event I hook up multiple app services via the inter-app-exposure mechanism).

And, of course, it has to be possible convert service apps to addons and vice versa.

[stuartpb]

So I think this means the terminology for apps:create is going to bifurcate into apps:init (and all "app/repo integration" will be moved out of its own plugin and into the apps system, where apps are now just inherently repo-aware), and apps:spawn or something like that, which instantiates a service app.

[stuartpb]

I'll probably leave apps:create as a synonym for apps:init because that's the path of least resistance (why bikeshed just to make the command that matches other platforms not match their name?)

In fact, since there's nobody relying on the old promises, I'll just change apps:create and not give it a new name. It means it calls an entirely new tree of hooks, but that's NBD.