Merge lp://staging/~openerp-dev/openobject-server/6.1-multicorn-al into lp://staging/openobject-server/6.1

Not for 6.1

Is --multiprocess a standard option name? I dislike it, because its name suggests a *boolean* option. Make uses --jobs (shortcut -j) for the same purpose, and I think that a bunch of tools use --jobs. I also saw --processes, that I find nice and unambiguous.

Some technical remarks:
- Remove line 375 in diff: apparently openerp.multi_process is not used anywhere else.
- Lines 625, 694 in diff: use "True" instead of "1".
- The class names "Unicron" and "Unicorn" are only a typo away. This confused me the first time I saw it. I suggest to increase their typo distance, and use something like "UnicornCron" or "UniCRON" to reduce confusion.

Raphael

Is psutil is really required ?

> Is --multiprocess a standard option name? I dislike it, because its name
> suggests a *boolean* option. Make uses --jobs (shortcut -j) for the same
> purpose, and I think that a bunch of tools use --jobs. I also saw
> --processes, that I find nice and unambiguous.

--workers ok ?

> Some technical remarks:
> - Remove line 375 in diff: apparently openerp.multi_process is not used
> anywhere else.

it is used, it enables db signaling for registry reload

> - Lines 625, 694 in diff: use "True" instead of "1".
> - The class names "Unicron" and "Unicorn" are only a typo away. This confused
> me the first time I saw it. I suggest to increase their typo distance, and
> use something like "UnicornCron" or "UniCRON" to reduce confusion.

It's was pun, i plan to rename them to HTTPWorker and CronWorker before the merge. :)

Small notes:

- Testing for 'HTTP_X_FORWARDED_HOST' in the environment to activate or not the ProxyFix is probably a security hole.

- You removed the gunicorn.conf.py file, but it is still mentioned in the other configuration file. Probably it would be better to still offer the possibility to run OpenERP behind Gunicorn (and possibly other WSGI servers).

More importantly:

I pretty much dislike the approach and I think we should use another one.

- Inspecting HTTP requests for smarter dispatching to workers can be done using a reverse proxy such as Nginx.

- Having a monitoring process dispatching requests using a pre-fork model to workers is already done is some existing tools. It would make sense to re-use them, preferably using those that are well-known, documented and tested. If we don't find a suitable projects, maybe we can contribute to one almost fullfilling our needs.

It is pretty sure that our own `multicorn` would never be correclty documented and tested. If we ever commit to make our own, it would also be better to make it a separate project, in order to attract more interest (i.e. from outside the OpenERP community, so the project has better chance to stand the test of time).

Existing projects are likely to have interesting features we would not have (such as inc/decrementing worker count, dynamic reconfiguration and hot-code reloading).

- The possibility to run separate processes with separate goals (such as the regular OpenERP server, and the Cron workers) is nice and already available in existing tools.

- Overall separating concerns into different tools/code base/processes is a desirable trait. For instance, mixing command-line arguments for a regular OpenERP server, and for Multicorn-enabled OpenERP is bad, as it is possible to achieve the same result in a cleaner way.