alvaro at sun
Apr 2, 2008, 4:30 AM
Post #7 of 9
(398 views)
Permalink
|
On 1 Apr 2008, at 18:03, Gunnar Wolf wrote:
> Alvaro Lopez Ortega dijo [Fri, Mar 28, 2008 at 12:38:16PM +0100]:
>> Let's try to be pragmatic here. Cherokee-admin does not support
>> splitted files, and moreover it will not support it in the near
>> future.
>>
>> In fact, I am not even sure whether it is desirable thing to
>> implement
>> in Cherokee. It looks much more like the "less stinky" solution for
>> dealing with text plain configuration files.
>>
>> Cherokee 0.5 used splitted configuration files because it was the
>> best
>> solution at that point, but things have changed a lot since then. In
>> fact, I have put a whole lot of work to get rid of it.
>>
>> In my opinion, it would make much more sense to allow the web based
>> applications to 'enhance' cherokee-admin by adding some sort of
>> definitions file. In fact, *the server configuration* is a single
>> thing that ought to be treated as such.
>>
>> Let's try not to copy the workarounds that other projects were forced
>> to implement. We should try to thing ahead that!
>
> Umh... I perfectly understand Cherokee is not by far among the most
> popular webservers - But looking at the standard practices both inside
> distributions (i.e. in Debian, that's what I can speak about) and for
> Web application authors, it's customary to ship your code with a very
> simple configuration snippet, following a easy to understand (or at
> least, widely understood) configuration syntax.
>
> Such developers should not be expected to write a configuration module
> for an obscure Webserver. They won't do it. That's more likely to
> isolate Cherokee even more.
Ummmm.. encouraging comments.. nice! :-)
> I do agree that, given the very-very-strong-preference for a
> registry-like configuration managed by a tool, the _core_
> configuration should be shipped as a single file (and yes, I'll merge
> the different configuration parts into one for Debian). But denying
> third parties the ease that means just shipping a configuration
> snippet will only ensure less public exposure for Cherokee.
>
> (BTW, the configurations generated by 05to06.py _do_ have an 'include'
> keyword)
Cherokee >=0.6 does support the "include" property and even a
"try_include" key for that legacy kind of environment that you were
referring to. However, that is what it is: legacy. We should no longer
use it if it is not strictly necessary. Besides, cherokee-admin does
not support it so if you use any of those keys you will have to manage
the configuration files by hand, and that is something that an average
user should not even think of doing.
In fact, supporting file inclusion in cherokee-admin would be trivial.
I do not think that it could require more than 10 additional lines of
code, but it would bring a tough problem though: included files would
be mixed with the original file, and therefore the updated
configuration file would contain the whole thing, leaving the original
included file lingering in the inclusion directory for ever.
So, being aware of the problem that you are exposing (that is a
problem, indeed), and knowing that the file inclusion mechanism is no
longer an option, we will have to figure out a new way to allow third
party web applications to include configuration snippets. The cherokee-
admin definition files (or modules) is something that we -the cherokee
project- will do for the most spread software, but that I do not
expect anyone else to do in the near term.
Would a command line utility for merging, removing and modifying
configuration files help here?
--
Greetings, alo.
_______________________________________________
Cherokee mailing list
Cherokee[at]cherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
|
