Open Stack

Yes, I also think this changes more refer to model than DSL


On Fri, Feb 28, 2014 at 1:41 PM, Renat Akhmerov <rakhmerov at mirantis.com>wrote:

> Yes. Guys, thanks for your feedback. I had a conversation with Dmitri
> today and realized you guys are right here. We should think about building
> basically a "domain model" which the system operates with and once we built
> it we should forget that we have some DSL or whatever we used to describe
> this model (could be other language, for example). Our initial intention
> actually was different but anyway what you're saying is valid. Looks like
> Nikolay agrees with me too and he's now reworking this commit. Coming up
> soon.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> On 27 Feb 2014, at 23:36, Manas Kelshikar <manas at stackstorm.com> wrote:
>
> I looked at the review prior to looking at the discussion and even I was
> confused by names like DSL*. The way I see it DSL is largely syntatic sugar
> and therefore it will be good to have a clear separation between DSL and
> model. The fact that something is defined in a DSL is irrelevant once it
> crosses mistral API border in effect within mistral itself DSLTask,
> DSLAction etc are simply description objects and how they were defined does
> not matter to mistral implementation.
>
> Each description object being a recipe to eventually execute a task. We
> therefore already see these two manifestations in current code i.e.
> DSLTask(per Nikolay's change) and Task (
> https://github.com/stackforge/mistral/blob/master/mistral/api/controllers/v1/task.py#L30
> ).
>
> To me it seems like we only need to agree upon names. Here are my
> suggestions -
>
> i)
> DSLTask -> Task
> Task -> TaskInstance
> (Similarly for workflow, action etc.)
>
> OR
>
> ii)
> DSLTask -> TaskSpec
> Task -> Task
> (Similarly for workflow, action etc.)
>
>
>
> On Wed, Feb 26, 2014 at 9:31 PM, Renat Akhmerov <rakhmerov at mirantis.com>wrote:
>
>>
>> On 26 Feb 2014, at 22:54, Dmitri Zimine <dz at stackstorm.com> wrote:
>>
>> Based on the terminology from [1], it's not part of the model, but the
>> language that describes the model in the file.
>>
>>
>> Sorry, I'm having a hard time trying to understand this phrase :) What do
>> you mean by "model" here? And why should DSL be a part of the model?
>>
>> And theoretically this may be not the only language to express the
>> workflow.
>>
>>
>> Sure, from that perspective, for example, JVM has many "DSLs": Java,
>> Scala, Groovy etc.
>>
>> Once the file is parsed, we operate on model, not on the language.
>>
>>
>> How does it influence using term DSL? DSL is, in fact, a user interface.
>> Model is something we build inside a system to process DSL in a more
>> convenient way.
>>
>>
>> I am afraid we are breaking an abstraction when begin to call things
>> DSLWorkbook or DSLWorkflow. What is the difference between Workbook and
>> DSLWorkbook, and how DSL is relevant here?
>>
>>
>> Prefix "DSL" tells that this exactly matches the structure of an object
>> declared with using DSL. But, for example, a workbook in a database may
>> have (and it has) a different structure better suitable for storing it in a
>> relational model.
>> So I'm not sure what you mean by saying "we are breaking an abstraction"
>> here. What abstraction?
>>
>> [1] https://wiki.openstack.org/wiki/Mistral,
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Nikolay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140228/6699fc65/attachment.html>