@Alex, @Svet, @Andrew: I get that it could be handy to use our YAML as JSON. Do you have any examples of this kind of use within the Brooklyn ecosystem? If not, this is not a compelling argument to me because again, our YAML is currently not valid: we shouldn't use any `$brooklyn:(.+)` as key if it is unwrapped. The example given by Andrew is the perfect example this issue: Brooklyn will not complain and process the blueprint whereas any other parser will reject it (which was why I made this proposal in the first place)
On Fri, 29 Jul 2016, 13:52 Svetoslav Neykov, < [email protected]> wrote: > Agree with that. Something I wrote a couple of hours ago while offline, so > didn't see Alex's email: > > Something to have in mind when discussing this - YAML is a superset of > JSON as all of you are well aware. Today we can express the Brooklyn CAMP > spec completely in JSON and it will just work. I've actually taken > advantage of this in browser clients, using the built-in JSON support to > convert objects in memory to markup, without needing to pull in any > external libraries. > > Svet. > > > > On 29.07.2016 г., at 9:54, Alex Heneveld < > [email protected]> wrote: > > > > The ability to switch between json and yaml (so we only use the > > json-isomorphic subset) is nice for working with models eg is js in the > > browser, and feels less intimidating to new people. I'd like anywhere we > > use !! to be optional. (if it were a more widely used part of yaml I > might > > think differently). > > > > Best > > Alex > > > > On 29 Jul 2016 03:35, "Andrew Kennedy" <[email protected] > > > > wrote: > > > >> Hi. > >> > >> The 'formatString' example you quote would normally be written like > this, > >> though: > >> > >> brooklyn.config: > >> brooklyn.example.db.url: > >> $brooklyn:formatString: > >> - "jdbc:%s%s?user=%s\\&password=%s" > >> - $brooklyn:component("db").attributeWhenReady("datastore.url") > >> - "visitors" > >> - "brooklyn" > >> - "br00k11n" > >> > >> So, I'm not sure what we gain here? I'll have a proper look at the YAML > >> spec, though, and see if I can understand it better. > >> > >> Cheers, > >> Andrew. > >> > >> On Wed, 13 Jul 2016 at 13:35 Thomas Bouron < > >> [email protected]> > >> wrote: > >> > >>> Hi All > >>> > >>> The YAML spec[1] has a very nice and standard way of defining custom > >> types > >>> by prefixing any value or object by a `!!<type_name>`. This seems like > a > >>> perfect feature for the Brooklyn DSL instead of the > >> `$brooklyn:<command>`. > >>> Let's me explain why. > >>> > >>> Right now, a Brooklyn DSL command needs to be written as a string such > >> as: > >>> $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", > >>> component("db").attributeWhenReady("datastore.url"), > >>> "visitors", "brooklyn", "br00k11n") > >>> However, any good YAML library (such as js-yaml[2]) to parse and dump > >> YAML > >>> <--> JSON would wrap this string in quotes because it contains quotes > or > >>> reserved characters. That is the expected behaviour based on the > >>> specification[3]. But this is an issue for the Brooklyn parser as the > >> value > >>> will be treated as a `String` and not as a `DslCommand` object. > >>> > >>> So my proposal is as follow: support the Brooklyn DSL as a standard > >> custom > >>> YAML type. We obviously need to avoid any quote or reserved characters. > >>> That is relatively simple for commands that takes only one parameter, > for > >>> instance: > >>> > >>> - $brooklyn:component('my-id') could become > >>> - !brooklyn:component my-id > >>> - $brooklyn:entitySpec would become > >>> - !brooklyn:spec > >>> > >>> For the more complex ones, I created a gist[4] that illustrates how > this > >>> could work. It is more verbose than the current version but we get a > rid > >> of > >>> the hacky `$brooklyn` and comply fully to the YAML specification. > >>> > >>> Best. > >>> > >>> [1] http://yaml.org/spec/1.2/spec.html > >>> [2] https://github.com/nodeca/js-yaml > >>> [3] http://yaml.org/spec/1.2/spec.html#id2788859 > >>> [4] https://gist.github.com/tbouron/67527796726e10689d8d3c34784cd7ec > >>> > >>> -- > >>> > >>> Thomas Bouron • Software Engineer @ Cloudsoft Corporation • > >>> http://www.cloudsoftcorp.com/ > >>> Github: https://github.com/tbouron > >>> Twitter: https://twitter.com/eltibouron > >>> > >> -- > >> > >> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > >> > > -- Thomas Bouron • Software Engineer @ Cloudsoft Corporation • http://www.cloudsoftcorp.com/ Github: https://github.com/tbouron Twitter: https://twitter.com/eltibouron
