You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Thomas Bouron <th...@cloudsoftcorp.com> on 2016/07/13 12:35:00 UTC
[PROPOSAL] Brooklyn DSL in YAML using custom YAML types
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
Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Hi Thomas-
> 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?
There are quite a few places this is done including when you deploy, the
first-pass parse at the Brooklyn server. It's a second pass interprets
$brooklyn:... as strings within the "jsonable" object (where I use that
term to describe a primitive, string, null, or list of jsonables, or map
with string keys and jsonable values).
There are also some graphical renderers/editors of blueprints which do
this -- with limited support for $brooklyn DSL strings/maps, but because
tools can simply treat them as jsonable objects it isn't a problem.
Svet describes some he has done, and I'd like to keep it easy for others.
While I like the ! capability of YAML to express types I worry that (a)
it is not widely understood and would make the blueprints harder for
people to read, and (b) it implies some knowledge of the type implied by
! in order to represent the object even on a first parse.
In short by preserving `$brooklyn:...` and `type: xxx` as stings on a
first class parse -- in other words by sticking with the JSON-isomorphic
subset -- the first-pass parse model becomes much simpler and easier for
external tools to work with.
I also question your claim that our YAML is hacky or non-compliant. The
YAML spec 7.3.3 says:
> Plain scalars must never contain the \u201c: \u201d and \u201c #\u201d character
combinations. Such combinations would cause
> ambiguity with mapping key: value pairs and comments. In addition,
inside flow collections, or when used as
> implicit keys, plain scalars must not contain [127] [128] [129] [130]
the \u201c[\u201d, \u201c]\u201d, \u201c{\u201d, \u201c}\u201d and \u201c,\u201d characters.
By my reading there is no restriction on an initial $ or intermediate
commas or quotes (as long as you aren't in a bracketed list) so the
example you give is valid YAML whether plain or single quoted, or double
quoted with double quotes escaped. The YML spec example 7.10 includes
as examples:
- Up up, and away!
- http://example.com/foo#bar
Re wrapping it in quotes, you write:
> this is an issue for the Brooklyn parser as the value will be treated
as a `String`
> and not as a `DslCommand` object.
Pretty certain this is not that case. You can wrap in quotes fine (or
indeed supply JSON which does this). The server expects '$brooklyn:...'
as a string, with the type conversion handled as a second pass. A
client does not need to know anything about the "DslCommand" library.
I know that some parsers eagerly quote but most will also generously
parse if the input is unambiguous, but that isn't often an issue and
where it is I think we can work around that by requesting that the
Brooklyn server return strict JSON rather than YAML (or try to patch the
buggy YAML library).
If you've got some specific parser issues share them -- that will be
interesting -- but I've had good experiences YAML-parsing with Node, Go,
and Ruby (although the Ruby one is a bit idiosyncratic).
--A
On 29/07/2016 16:03, Thomas Bouron wrote:
> @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, <
> svetoslav.neykov@cloudsoftcorp.com> 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 \u0433., at 9:54, Alex Heneveld <
>> alex.heneveld@cloudsoftcorp.com> 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" <andrew.kennedy@cloudsoftcorp.com
>>>
>>> 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 <
>>>> thomas.bouron@cloudsoftcorp.com>
>>>> 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 \u2022 Software Engineer @ Cloudsoft Corporation \u2022
>>>>> http://www.cloudsoftcorp.com/
>>>>> Github: https://github.com/tbouron
>>>>> Twitter: https://twitter.com/eltibouron
>>>>>
>>>> --
>>>>
>>>> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
>>>>
>> --
> Thomas Bouron \u2022 Software Engineer @ Cloudsoft Corporation \u2022
> http://www.cloudsoftcorp.com/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>
Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
@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, <
svetoslav.neykov@cloudsoftcorp.com> 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 <
> alex.heneveld@cloudsoftcorp.com> 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" <andrew.kennedy@cloudsoftcorp.com
> >
> > 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 <
> >> thomas.bouron@cloudsoftcorp.com>
> >> 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
Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
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 <al...@cloudsoftcorp.com> 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" <an...@cloudsoftcorp.com>
> 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 <
>> thomas.bouron@cloudsoftcorp.com>
>> 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
>>
Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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" <an...@cloudsoftcorp.com>
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 <
> thomas.bouron@cloudsoftcorp.com>
> 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
>
Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Posted by Andrew Kennedy <an...@cloudsoftcorp.com>.
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 <th...@cloudsoftcorp.com>
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
Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
Hi Thomas,
Don't have an opinion on the custom types yet. I'm not sure I understand the reasoning behind the proposal. Are you saying that if we use xxx: "$brooklyn:formatString(\"jdbc:...\", component(\"db\").attributeWhenReady(\"url\"))" it won't get converted to a DslComponent, but will be used as the plain string instead? Brooklyn will convert the string to an object after the parsing stage, so it doesn't really care what format was used for serializing it, that's why I want to confirm if that's what's happening.
Svet.
> On 13.07.2016 г., at 15:35, Thomas Bouron <th...@cloudsoftcorp.com> 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