Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800: > On 12/11/14 10:10, Clint Byrum wrote: > > Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800: > >> On 11/11/14 13:34, Ryan Brown wrote: > >>> I am strongly against allowing arbitrary Javascript functions for > >>> complexity reasons. It's already difficult enough to get meaningful > >>> errors when you **** up your YAML syntax. > >> > >> Agreed, and FWIW literally everyone that Clint has pitched the JS idea > >> to thought it was crazy ;) > >> > > > > So far nobody has stepped up to defend me, > > I'll defend you, but I can't defend the idea :) > > > so I'll accept that maybe > > people do think it is crazy. What I'm really confused by is why we have > > a new weird ugly language like YAQL (sorry, it, like JQ, is hideous), > > Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is > probably not the way to win over Python developers :D > > > and that would somehow be less crazy than a well known mature language > > that has always been meant for embedding such as javascript. > > JS is a Turing-complete language, it's an entirely different kettle of > fish to a domain-specific language that is inherently safe to interpret > from user input. Sure, we can try to lock it down. It's a very tricky > job to get right. (Plus it requires a new external dependency of unknown > quality... honestly if you're going to embed a Turing-complete language, > Python is a much more obvious choice than JS.) >
There's a key difference though. Python was never designed to be run from untrusted sources. Javascript was _from the beginning_. There are at least two independent javascript implementations which both have been designed from the ground up to run code from websites in the local interpreter. From the standpoint of Heat, it would be even easier to do this. Perhaps I can carve out some of that negative-1000-days of free time I have and I can make it a resource plugin, with the properties being code and references to other resources, and the attributes being the return. > > Anyway, I'd prefer YAQL over trying to get the intrinsic functions in > > HOT just right. Users will want to do things we don't expect. I say, let > > them, or large sections of the users will simply move on to something > > else. > > The other side of that argument is that users are doing one of two > things with data they have obtained from resources in the template: > > 1) Passing data to software deployments > 2) Passing data to other resources > > In case (1) they can easily transform the data into whatever format they > want using their own scripts, running on their own server. > > In case (2), if it's not easy for them to just do what they want without > having to perform this kind of manipulation, we have failed to design > good resources. And if we give people the tools to just paper over the > problem, we'll never hear about it so we can correct it at the source, > just launch a thousand hard-to-maintain hacks into the world. > I for one would rather serve the users than ourselves, and preventing them from papering over the problems so they have to whine at us is a self-serving agenda. As a primary whiner about Heat for a long time, I respect a lot that this development team _bends over backwards_ to respond to user requests. It's amazing that way. However, I think to grow beyond open source savvy, deeply integrated users like me, one has to let the users solve their own problems. They'll know that their javascript or YAQL is debt sometimes, and they can come to Heat's development community with suggestions like "If you had a coalesce function I wouldn't need to write it in javascript". But if you don't give them _something_, they'll just move on. Anyway, probably looking further down the road than I need to, but please keep an open mind for this idea, as users tend to use tools that solve their problem _and_ get out of their way in all other cases. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
