Eric S. Johansson wrote, On 17/01/07 02:11:

 >> 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).
 >
 > I'm in the same camp.  I've looked at a third path a.k.a json
 > (http://www.json.org/) for other projects and wonder if json had been
 > considered.

   I've checked Json and Yaml one more time. First of all, I have to
   say that I don't like any of them. They try to be easy and user
   friendly, but they are quite hard to be handled by hand.

   I tried to make my mind up by writing the same configuration example
   on each format. Check it out.

   First of all, in the current 0.6-proposed format:

========
server!port = 80
server!port_tls = 443
server!timeout = 60
server!pid_file = /var/run/cherokee.pid

vserver!default!document_root = /tmp
vserver!default!directory!/!handler = file
vserver!default!directory!/tmp!handler = common
vserver!default!directory!/tmp!document_root = /var/tmp
vserver!www.example.com!document_root = /tmp
========

   With Json notation it's quite painful; even worse than in the
   proposed 0.6 format:

========
{
   "server": {
     "port": 80,
     "port_tls": 443,
     "timeout": 60
     "pid_file": "/var/run/cherokee.pid"
   },

   "vserver": {
      "default": {
           "document_root": "/tmp",
           "directory": {
                 "/": {
                     "handler": "file"
                  },
                 "/tmp": {
                    "handler": "common",
                    "document_root": "/var/tmp"
                  }
           }
        },
      "www.example.com": {
           "document_root": "/tmp",     
      }
    }
}
========

   On Yaml notation it isn't that bad tough. However it's far from
   being comfortable:

========
server:
     port     : 80
     port_tls : 443
     timeout  : 60
     pid_file : /var/run/cherokee.pid

vserver:
     default:
         document_root: /tmp
           directory:
               /:
                    handler : file
               /tmp:
                    handler       : common
                    document_root : /var/tmp
     www.example.com:
           document_root: /tmp
========

   You have to try to write it down to realized of unnatural is to
   write that "/:" line.

   So, any of the proposed formats seem to be the perfect solution.
   Whether some of them is better or not would be based on the taste of
   each one, I guess.

   So far, the only thing I could think of to improve the current 0.6
   format is to add some bits of Yaml format. What would you think of
   something like this?

========
server:
     port     = 80
     tls_port = 443
     timeout  = 60
     pid_file = /var/run/cherokee.pid

vserver!default:
     document_root = /tmp
     directory:
         /!handler = file
           /tmp!handler = common
           /tmp!document_root = /var/tmp

vserver!www.example.com:
     document_root = /tmp
========

   which would be the exactly the same as:

========
server:
     port     = 80
     tls_port = 443
     timeout  = 60
     pid_file = /var/run/cherokee.pid

vserver!default:
     document_root = /tmp
     directory!/!handler = file
     directory!/tmp:
           handler = common
           document_root = /var/tmp

vserver!www.example.com!document_root = /tmp
========

   Basically, we would be adding blocks to the current notation.

   However, I'm not sure at all if that's the way.
   Thoughts? Ideas? Proposals?

-- 
Greetings, alo.
_______________________________________________
Cherokee mailing list
[email protected]
http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee

Reply via email to