<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div dir="ltr" id="yui_3_16_0_1_1415865043908_16697"><span id="yui_3_16_0_1_1415865043908_16722">Will be very interesting to see how this plays out.</span></div><div id="yui_3_16_0_1_1415865043908_16708" dir="ltr"><br><span></span></div><div id="yui_3_16_0_1_1415865043908_16724" dir="ltr"><span id="yui_3_16_0_1_1415865043908_16723">FYI, yql (a thing yahoo uses a-lot of, internally and externally) has this kind of functionality built-in.</span></div><div id="yui_3_16_0_1_1415865043908_16707" dir="ltr"><br><span></span></div><div id="yui_3_16_0_1_1415865043908_16726"><a id="yui_3_16_0_1_1415865043908_16725" href="https://developer.yahoo.com/yql/guide/yql-execute-chapter.html">https://developer.yahoo.com/yql/guide/yql-execute-chapter.html</a></div><div id="yui_3_16_0_1_1415865043908_16737"><br></div><div id="yui_3_16_0_1_1415865043908_16854">I am unaware of any python version of a javascript engine that has rate/execution limiting and such[2], so I'm not sure how feasible this is without switching languages (to java using rhino[3] or one of the firefox monkey engines or chromes engine...).<br></div><div id="yui_3_16_0_1_1415865043908_16747"><br></div><div id="yui_3_16_0_1_1415865043908_16748" dir="ltr">It would though be neat to expose javascript functions to heat so that people could extend heat where they felt they needed to and 'glue' together there various javascript functions into a larger orchestration template that heat manages (and/or use native heat functionality that exists). That would seem like a good mix of functionality for people to have (and enables more advanced users); although it does of course introduce a bunch of complexity (first being where does this javascript code get ran, where is it stored...).<br></div><div id="yui_3_16_0_1_1415865043908_16749"><br></div><div id="yui_3_16_0_1_1415865043908_16751" dir="ltr">[2] <a id="yui_3_16_0_1_1415865043908_16750" href="https://developer.yahoo.com/yql/guide/yql-execute-intro-ratelimits.html">https://developer.yahoo.com/yql/guide/yql-execute-intro-ratelimits.html</a></div><div id="yui_3_16_0_1_1415865043908_16868" dir="ltr">[3] <a id="yui_3_16_0_1_1415865043908_16873" href="http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29">http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29</a><br></div><div id="yui_3_16_0_1_1415865043908_16863" dir="ltr"><br></div><div id="yui_3_16_0_1_1415865043908_17172" dir="ltr">-Josh<br></div><div id="yui_3_16_0_1_1415865043908_17173" dir="ltr"><br></div><div id="yui_3_16_0_1_1415865043908_16674" style="font-family: HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_1_1415865043908_16673" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_1_1415865043908_16672" dir="ltr"> <hr id="yui_3_16_0_1_1415865043908_16742" size="1"> <font id="yui_3_16_0_1_1415865043908_16671" face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> Clint Byrum <clint@fewbar.com><br> <b id="yui_3_16_0_1_1415865043908_16736"><span id="yui_3_16_0_1_1415865043908_16735" style="font-weight: bold;">To:</span></b> openstack-dev <openstack-dev@lists.openstack.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, November 12, 2014 10:00 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull<br> </font> </div> <div id="yui_3_16_0_1_1415865043908_16698" class="y_msg_container"><br>Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800:<br clear="none">> On 12/11/14 10:10, Clint Byrum wrote:<br clear="none">> > Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:<br clear="none">> >> On 11/11/14 13:34, Ryan Brown wrote:<br clear="none">> >>> I am strongly against allowing arbitrary Javascript functions for<br clear="none">> >>> complexity reasons. It's already difficult enough to get meaningful<br clear="none">> >>> errors when you **** up your YAML syntax.<br clear="none">> >><br clear="none">> >> Agreed, and FWIW literally everyone that Clint has pitched the JS idea<br clear="none">> >> to thought it was crazy ;)<br clear="none">> >><br clear="none">> ><br clear="none">> > So far nobody has stepped up to defend me,<br clear="none">> <br clear="none">> I'll defend you, but I can't defend the idea :)<br clear="none">> <br clear="none">> > so I'll accept that maybe<br clear="none">> > people do think it is crazy. What I'm really confused by is why we have<br clear="none">> > a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),<br clear="none">> <br clear="none">> Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is <br clear="none">> probably not the way to win over Python developers :D<br clear="none">> <br clear="none">> > and that would somehow be less crazy than a well known mature language<br clear="none">> > that has always been meant for embedding such as javascript.<br clear="none">> <br clear="none">> JS is a Turing-complete language, it's an entirely different kettle of <br clear="none">> fish to a domain-specific language that is inherently safe to interpret <br clear="none">> from user input. Sure, we can try to lock it down. It's a very tricky <br clear="none">> job to get right. (Plus it requires a new external dependency of unknown <br clear="none">> quality... honestly if you're going to embed a Turing-complete language, <br clear="none">> Python is a much more obvious choice than JS.)<br clear="none">> <br clear="none"><br clear="none">There's a key difference though. Python was never designed to be run<br clear="none">from untrusted sources. Javascript was _from the beginning_. There are<br clear="none">at least two independent javascript implementations which both have been<br clear="none">designed from the ground up to run code from websites in the local<br clear="none">interpreter. From the standpoint of Heat, it would be even easier to do<br clear="none">this.<br clear="none"><br clear="none">Perhaps I can carve out some of that negative-1000-days of free time I<br clear="none">have and I can make it a resource plugin, with the properties being code<br clear="none">and references to other resources, and the attributes being the return.<br clear="none"><br clear="none">> > Anyway, I'd prefer YAQL over trying to get the intrinsic functions in<br clear="none">> > HOT just right. Users will want to do things we don't expect. I say, let<br clear="none">> > them, or large sections of the users will simply move on to something<br clear="none">> > else.<br clear="none">> <br clear="none">> The other side of that argument is that users are doing one of two <br clear="none">> things with data they have obtained from resources in the template:<br clear="none">> <br clear="none">> 1) Passing data to software deployments<br clear="none">> 2) Passing data to other resources<br clear="none">> <br clear="none">> In case (1) they can easily transform the data into whatever format they <br clear="none">> want using their own scripts, running on their own server.<br clear="none">> <br clear="none">> In case (2), if it's not easy for them to just do what they want without <br clear="none">> having to perform this kind of manipulation, we have failed to design <br clear="none">> good resources. And if we give people the tools to just paper over the <br clear="none">> problem, we'll never hear about it so we can correct it at the source, <br clear="none">> just launch a thousand hard-to-maintain hacks into the world.<br clear="none">> <br clear="none"><br clear="none">I for one would rather serve the users than ourselves, and preventing<br clear="none">them from papering over the problems so they have to whine at us is a<br clear="none">self-serving agenda.<br clear="none"><br clear="none">As a primary whiner about Heat for a long time, I respect a lot that<br clear="none">this development team _bends over backwards_ to respond to user<br clear="none">requests. It's amazing that way.<br clear="none"><br clear="none">However, I think to grow beyond open source savvy, deeply integrated<br clear="none">users like me, one has to let the users solve their own problems. They'll<br clear="none">know that their javascript or YAQL is debt sometimes, and they can<br clear="none">come to Heat's development community with suggestions like "If you had<br clear="none">a coalesce function I wouldn't need to write it in javascript". But if<br clear="none">you don't give them _something_, they'll just move on.<br clear="none"><br clear="none">Anyway, probably looking further down the road than I need to, but<br clear="none">please keep an open mind for this idea, as users tend to use tools that<br clear="none">solve their problem _and_ get out of their way in all other cases.<div class="qtdSeparateBR"><br><br></div><div class="yqt5485876598" id="yqtfd49047"><br clear="none"><br clear="none">_______________________________________________<br clear="none">OpenStack-dev mailing list<br clear="none"><a shape="rect" ymailto="mailto:OpenStack-dev@lists.openstack.org" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br clear="none"><a shape="rect" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br clear="none"></div><br><br></div> </div> </div> </div></body></html>