[meta] Lay groundwork for non-Drupal applications

Being able to independently create virtualhosts and databases would be really useful. Sometimes you want another vhost, and sometimes you want an extra database (like for more complex sites).

I think once you actually dig into this, multisite isn't that hard at all... it's simply any site that has the same file path as another site, right? That association alone would be enough to say, "These two sites are a part of a multisite".

Wouldn't the platform name-space make a lot of sense for the type of project / CMS in question? Don't want to muddy that name-space in the AEgir community but when I think of Wordpress I think of a Platform (that happens to be a CMS) or an Application.

Mental map

Application (right now Drupal is the default but this could integrate any application)
-- Platform (OpenPublish or OpenPublish For Vendor N+1)
---- Instance 1 (Client N)
---- Instance 2 (Client N+1)

In this way, the instances of a platform are an additional site running off the same code base and so it becomes a multi-site, but the word multi-site is never used.

That's very true. Another side effect of this is that you always end up with a sites/default site in Drupal, so there's always a default site and then any multisites are just addons, which makes sense in my mind.

Have you seen the way that DSLM (https://drupal.org/project/dslm) treats multi-sites? It basically creates a series of drush commands that allow you to stitch together a platform from an application. In DSLM's case that's a drupal core / release paired with an install profile. It then lets you stuff these where ever you want. I build on-top of this in ELMSLN to support the notion of "stacks", basically an intersection of profiles and drupal cores and then author new sites into those multi-sites. Example: https://github.com/btopro/elmsln/tree/master/core/dslmcode/stacks

I'm coming at this from the outside and just trying to get more involved in AEgir / Devshop so wanted to throw my 2-cents in as to how an outsider is starting to tackle some of these issues. Galaxy packaging format that ELMSLN uses supports / is planning out how to support non-drupal platforms but it's at a file-structure level, less a GUI (for now).

Just remember: you can improve terminology, expand it, but you can't overwrite/alter existing terminology with new meanings.

I think it's going to be a bit easier to write this from the ground up as a separate type of "thing" in Aegir, rather than trying to fit it into the existing codebase.

I'd suggest building this in contrib, and then re-including it as part of the 'golden' contrib initiative. This will allow contributors outside of the Aegir core team to participate directly. That said, I think it's a great idea, and could well form the basis of a new 'core' for Aegir 4+.