[Catalyst] YAML vs. *

[Matt S Trout]

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/ +