Kiki wrote: > Matt S Trout wrote: >> I love YAML as a serialisation format for data transfer, but so far as stuff >> like config files that are designed for human write / machine read, I >> personally think it sucks. Massively. >> >> And for hysterical raisins it's currently our default config file formats, >> and >> I see users running into trouble getting their myapp.yml to parse right all >> the flipping time. So, I'm wondering if this is just me being a YAML-hating >> heretic or if other people are of the same opinion. >> > OK, bikeshed painting time.... > > Decision-taking offtopical $0.02: I recently read a book in which the > author suggests to have people make preference lists and choose the most > common _second_ choice listed, based on the theory that people would put > their (sometimes/mostly unreasonable) "pet" choice first and the most > reasonable choice after that. Of course it would require either honest > choices or the people involved not to be aware of the selection process ...
Yeah, quite possibly. Maybe we need a catdot.org and a poll :) > Here would be my preference list (based on actual usage in the apps I > maintain): > 1. YAML: yes, the whitespace/indent issue is pretty frustrating, apart > from that no complaints, simple configs are easy to parse (and to write > once you take care of proper indentation/no tabs), complex configs are > possible > 2. INI: is even easier to write/read than yaml, widely understood and > all, but alas, unable to express more complex data structures (actually > I use a similar module which uses "." as a special key separator char to > provide for deeper hashes. Arrays could be expressed by repeating the > last key) > 3. Apache-style: OK, but ..., lack of explicit key/value separator kinda > confusing, xml style closing </Tag> makes it a bit too verbose for my > own liking. also how do you express deeper hashes, did I miss that? <Foo> <Bar> Baz Quux </Bar> </Foo> { Foo => { Bar => { Baz => 'Quux' } > 4. JSON: never used it so it gets the last place .... as somebody said > before, looks like a subset of yaml with more separators and less > whitespace nazism > > Then again, how about providing a config converter (for conversions that > make sense, usually simple config -> more complex ones, ini/apache -> > yaml/json): catalyst_config.pl --convert_to json myapp.ini Should be easy. At least YAML, JSON and Config::General support "here's a data structure, serialise it for me please". > For tutorials and (simple) config examples, simple, widely known and > robust is better, therefore INI-style would be the best choice. Apache > style second (not as widely known) Are you sure that's true for people deploying webapps? > For defaults when generating an new app, perhaps a switch to specify > default format, with default format value same as the one used in > tutorials so as not to confuse newbies, and even if you forgot to > specify one you could use the conversion tool... Yeah, but first let's get a cribsheet into the default .yml file and then we can look at hacking on catalyst.pl's functionality ... -- Matt S Trout Offering custom development, consultancy and support Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + _______________________________________________ List: [EMAIL PROTECTED] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/