Phew! Everything seems to work now: functions are parsed and evaluated
properly. But there are some changes that require explaining.

The "configuration" field in OperationTemplate and Operation models is now
a many-to-many with Parameter. This allows the values to fully support
intrinsic functions and types.

And I made another change in modeling: Operation now also has "function"
and "arguments" fields, which are what actually gets used by the Task API
instead of "implementation" and "inputs". This means that the
"implementation" and "inputs" values are preserved as is. During the
configuration phase the "arguments" are created according to the usual
logic: for the execution plugin, the "configuration" is massaged into a few
new "arguments", and otherwise other "inputs" are also merged into
"arguments".

Why make this change? Because I really think we should not mangle the
"inputs": they are logically different from the arguments that get sent to
the @operation function, even if in many cases we might treat them
identically. Also, we cannot lose the "implementation" string: plugins will
need to know what users put in there. The change is not big in terms of
extra code, but I think it helps make the code easier to understand: you
can see exactly what is being merged into the final "arguments" for the
task. The configure phase is now constructive rather than destructive:
existing fields are not changed.

Before moving forward with a PR I want to see what other committers think
about also renaming "implementation" and "inputs" in the Task API to
"function" and "arguments". For now I'm leaving them as is, but I think it
would be even cleaner if they followed the new naming convention in
modeling. I continue being unhappy about how the Task API treats both
arguments and inputs as the same thing and squashing them all together...
:( However, for now I would be happy if we just called them "arguments",
because that's what they really are for us.

-- 
Tal Liron
Solution Architect
t...@gigaspaces.com | +13123758299
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=general_signature>

Reply via email to