Separate out the http service, file service and backend service.

one thing that occurred to me is that we should consider dropping the ability to have multiple backends (for now).

The entire problem space becomes _drastically_ simplified when we make that assumption. The canonical platforms are thus stored on a single server , and each of the possible web heads gain access to them through one of the possible file service implementations (ie: through a mount of through rsync).

The requirement to be able to distribute and gain access to the backup files across various servers becomes a non-issue, because it's the backend service that needs access to the backup tarball, not the web heads. It turns the migrate between server problem on it's head, in that all that's changing is which web server is serving the site to the world outside, not where the drush commands are being run.

I'm still trying to figure it out, but i suspect that by focussing on the 'spoke model' described above and getting it properly implemented first, we will actually hit more than 90% of our actual use case requirements.

When we get to the point where we need to have multiple backends (mesh model), we will have reached the limits of the current "push" model of dispatching tasks from the queue, and we reach a situation where we _SERIOUSLY_ need to consider solutions such as REDIS/RESQUE to actually take advantage of the additional processing power.

I think we can make this better, but i like the approach here ...

Specifically instead of the path(), we need to make it the actual method (for now).

so :

provision_service('file')->unlink($filename);

i wonder, if _later_ , we can have the methods return objects too. so you can do

provision_service('file')->chmod('filename', 0664)->success("message")->fail("message");

I think we can make this better, but i like the approach here ...

Specifically instead of the path(), we need to make it the actual method (for now).

so :

provision_service('file')->unlink($filename);

i wonder, if _later_ , we can have the methods return objects too. so you can do

provision_service('file')->chmod('filename', 0664)->success("message")->fail("message");

I committed the patch here, so we're on the same page again for the following bit of work.

this is basically what the apache config stuff starts looking like :

http://gist.github.com/346501

it can still be made a lot cleaner, and doesn;t really work yet.

the idea is that each service implementation, has a class for each config file it implements, and this config file object knows it's template file, and has a method to determine it's final resting place.

what the delete_site_config etc methods will eventually do is make sure we pass the right object / data set into the object constructor (which we will get from the aliases).

I still need to figure out what to do with the variables associated with the config files..

for instance.. we need a backend service that initializes and verifies the global backup and config file directories.
Some of the stuff (ie: drupal_root and the drupal sites paths, also need to be moved out of the apache / http context, i *think*).

this stuff is evolving fast, and i hope to commit some wokring code int he next few days.

i committed this because it's exactly what's needed.

onwards =)

committed the last patch.

need to merge into envobject next.