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
_______________________________________________
Cherokee mailing list
[email protected]
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
