On 2007-01-16 14:55:39 -0700, Gunnar Wolf <[EMAIL PROTECTED]> said: > Andy Delcambre dijo [Sat, Jan 13, 2007 at 04:59:35AM -0800]: >> I just built cherokee from svn trunk to play with the new 0.6.0 >> features. I was surprised to see that the config syntax is completely >> different, for example: >> Old: >> Port 80 >> New: >> server!port = 80 >> (...) >> Is there some tool I haven't found yet? Or some documentation on the > n > ew syntax? > Hmh... Let me please hijack this thread, as I was just talking with > Álvaro about this topic - I'll just paste here a translation of our > conversation. Just as background: I talked with Álvaro in ~October > about this new configuration file syntax - It will be mainly > autogenerated, and while a human must be able to hand-edit it, he > hates XML. So do I. I sent him to check YAML [1], which is much better > suited IMHO. > > G: I'm discussing with some friends who push for XML as a > configuration file format... And well, I have not had time to think > about this in regard to Cherokee, but I recall having talked you > into YAML :) > G: ...Didn't you like it after all? > A: Yes, I looked at YAML. > A: The problem I found is the C implementation. It's still at 0.1, and > quite quite huge. > G: Oh... I understand the reasoning behind your level1!level2!foo!bar, > but... It looks _terrible_! ;-) > A: I know the exclamations are terrible, but so far, it's the best of > the realistic options I have seen. > G: Ok, but... If you use a simplified version of YAML? > A: You mean... Writing the parser? > G: Something that might look pythonesque, like: > level1: > key: value > level2: > key: value > key2: value2 > G: You don't really need full YAML, it's really (I'm looking at its > spec) much more than what Cherokee needs - although it covers its > basic needs. But maybe having some visual nesting, easy to follow > for the program... > G: Maybe a space-indented block following the trailing ':' on the > previous line, although this would require to prohibit using tabs, > or giving them a determined width... > A: Wouldn't that just be too complex? > G: But it would be much more editable. > A: It might end up being just worse... > G: For a human, editing your exclamation-based configuration just > looks terrible. And say what you want... But a human must be _able_ > to edit the configuration, even if there are tools for it! > A: The thing is that with the architecture we currently have, we could > even write backends, even for configuration reading, so in > principle it's not a problem to write a new on. > G: Of course, that does not sound too hard to implement... But hey, > having official 0.6 ship with _SUCH_ an ugly > configuration... Honest, I would not be surprised it will even > alienate some potential users :( > A: Ok, lets do something: Public debate, and let there be light, > right? > G: Ok, so be it. > A: Send it to the list, and we'll see what others think about it. > A: All in all, I don't think it will be so hard to get this > changed. We could even make it in time for 0.6 :) > > So, people: What do you think? I want three basic things: > > 1- Human readable/editable. And no, I don't see either XML or > a!long!string!of!elements followed by > a!long!string!of!repeated!elements implementing a perverted kind of > nesting as human-editable - It would surely lead to pain! > > 2- The ability to have comments. Yes, probably (and specially in its > first iterations) the automated config editing tools might not > respect the comments as much as you would like, but that's a minor > thing that can be fixed later. > > 3- Making it hard to introduce confusion by skipping order. As an > example: > > server!port = 80 > server!limit_connections!per_second = 100 > virtualhost!bar = foo.domain.org > virtualhost!foo = bar.domain.org > virtualhost!bar!documentroot = /var/www/foo > virtualhost!foo!documentroot = /var/www/bar > virtualhost!foo!handler = cgi > server!handler = file > > What do I show here? Yes, for the parser there is no ambiguity - But > for somebody just glancing over, it will look fine - It will be hard > to spot that the 'bar' vhost points to /var/www/foo and 'foo' points > to /var/www/bar. Oh, and somebody at the very end just added that > the base handler should be 'file'. Well, that should be placed next > to the other 'server' entries! > Yes, it would easily be solved by demanding the configuration file > to be sorted alphabetically. But if you don't _require_ it (or else > just work but spew a warning, or something like that), people _will_ > get confused. And they will bitch and hate Cherokee. And we don't > want that. ;-) > > Greetings, > > -- > Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 > PGP key 1024D/8BB527AF 2001-10-23 > Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
This is a very interesting thread that is about to get started. The bottom-line for me is that I fall on both sides of the fences. I really like having the ability to edit the server configuration file by hand. The current 0.6 configuration syntax is quite honestly and pain in the ass. I also really like the idea of having a web interface to the configuration file for quick edits or more complex integrations. It does mean more code to maintain, but it is already where Cherokee is heading. I looked a little into the YAML stuff. Quite honestly YAML makes me more sick than XML. Perhaps it is just a misconception I have with it or the fact that it is something new to me and I don't want to spend the time to learn it. XML is just too big and bulky (much like Java for me. Maybe that is why those two get along). The previous syntax in versions before 0.6 is perfect for a human to edit. I loved it and it is the main reason why I started to use Cherokee. It made me feel good about using it. I see alo's point with changing the syntax to make it easier to parse and write as a computer process. I feel that Cherokee should revert to its original syntax and write a parser for it in Python to allow for the web interface to work with it. Quite honestly, the parser is written for the most part in the 05to06.py file. I firmly believe that Cherokee needs to get back to a simple to use configuration syntax and for interfaces to the configuration files need to support something that is much more human readable. It will help with the exposure of Cherokee and to help beat the other open source competitors in the tiny webserver arena. Just my two cents. :) -- Brian Rosner http://www.brosner.com/blog _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
