On 30/11/10 10:08, Roberto De Ioris wrote:
Hi all, i am about to release a new uWSGI wizard, but before committing it
i would like to hear some comments or objections :)
Currently uWSGI supports 3 configuration file format:
[...]
So i think it would be better to reduce the uWSGI wizard at a simple
text input field that will take one of this file.
+1. The simpler for the user, the better :)
YAML parsing requires the python yaml module that could be not available in the
system, so i will
insert a check that will not show .yml extension in the form if it s not
available.
+1
Should uWSGI logging be disabled by default if not specified in config files ?
Without config files uWSGI will spawn a single worker. What do you think about
setting
the number of processes based on the number of cpus in the system ? (a ncpu*2
should be a good default value)
Looks like a sensible approach to me.
The newer uWSGI codebase contains a new option "manage-script-name" that will
manage suburl-application mapping
itself (without the help of the webserver). I think it could be better to
disable mountpoint parsing in case it is specified and simply
"mount" the uWSGI source under /
The basic idea behind the wizards is to provide a working configuration
for common scenarios, and a good starting point for those that are not
so common. While fully supporting the app is preferable, it makes sense
to provide only a limited subset of functionality if complexity begins
to grow without control. Even allowing wizards to work just for one of
new-virtual-server/directory-based mode (instead of both) makes sense
for some scenarios.
Having said that, it looks like you've been giving it quite some
thought. I'm sure many users will be looking forward to this wizard. I
can't wait to take a peak :)
Regards,
Taher
--
[email protected]
http://unixwars.com/
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
