[chef-dev] Re: Re: Re: Dialect support and loading enhancements

[Noah Kantrowitz < >]

On Oct 2, 2013, at 2:21 PM, Daniel DeLeo 
<
 >
 wrote:

> 
> On Wednesday, October 2, 2013 at 2:18 PM, Noah Kantrowitz wrote:
> 
>> 
>> On Oct 2, 2013, at 2:05 PM, Daniel DeLeo 
>> <
 >
>>  wrote:
>> 
>>> Chatted with the other folks at Opscode, and here's what we want to do
>>> (you can read this as a gist if the formatting is messed up: 
>>> https://gist.github.com/danielsdeleo/18c4e4e2bba6eff922d4 ;):
>>> 
>>> # Summary:
>>> 
>>> * Yes to "tiny" cookbook layouts
>>> * Yes to removing implicit filespecificity
>>> * Yes to user-defined, explicit filespecificity
>>> * Yes to modular, modifiable code that can support dialects
>>> * No to including any dialects in core or supporting them beyond
>>> best-effort Open Source Community courtesy.
>> 
>> Which dialects do you mean in particular? Ruby support itself is now setup 
>> as a dialect, so that one needs to be there. Beyond that I'm working on 
>> expanding the dialect system to encompass the decoder dispatch for stuff 
>> like metadata.{rb,json}, role files, and env files all of which will mean 
>> a built-in JSON dialect in addition to the Ruby one. Then there is the 
>> JSON and Yaml dialects I setup for attribute files, just to be clear I 
>> think you are suggesting those should be relocated to external cookbooks?
> We wanted to all get on the same page before we started reviewing the code, 
> so I can't be specific about details of the patch. That said, yes, 
> attributes need to stay ruby-only in core.

Okay, I disagree personally but we'll all see what the community uptake is 
and a year from now we can see what people settle on. What about the issue of 
JSON dialects for existing data types and the possibility of adding Yaml for 
those too (notably data bags would benefit greatly there I think)?

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail