Re: [openstack-dev] [Mistral] Defining term DSL
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 ma...@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 rakhme...@mirantis.com wrote: On 26 Feb 2014, at 22:54, Dmitri Zimine d...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Defining term DSL
Yes, I also think this changes more refer to model than DSL On Fri, Feb 28, 2014 at 1:41 PM, Renat Akhmerov rakhme...@mirantis.comwrote: 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 ma...@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 rakhme...@mirantis.comwrote: On 26 Feb 2014, at 22:54, Dmitri Zimine d...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Nikolay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Defining term DSL
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 rakhme...@mirantis.comwrote: On 26 Feb 2014, at 22:54, Dmitri Zimine d...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Defining term DSL
Due to the comment to https://review.openstack.org/#/c/75888/1 there is a quiestion: Do we use term DSL or something else? I think the word 'DSL' is more fit thing that we call 'workbook definition', some text describing workflows, services, tasks and actions. And processing module for this also has name 'dsl'. Thoughts? Dmitri? Nikolay, Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Defining term DSL
I don’t see any issues with term DSL (Domain Specific Language). This is really a language which 'workbook definitions’ are written in. Dmitri, could you please provide more details on why you question it? Thanks Renat Akhmerov @ Mirantis Inc. On 26 Feb 2014, at 20:12, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Due to the comment to https://review.openstack.org/#/c/75888/1 there is a quiestion: Do we use term DSL or something else? I think the word 'DSL' is more fit thing that we call 'workbook definition', some text describing workflows, services, tasks and actions. And processing module for this also has name 'dsl'. Thoughts? Dmitri? Nikolay, Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Defining term DSL
We do use the term DSL, I invite you guys to clarify, how exactly. Based on the terminology from [1], it's not part of the model, but the language that describes the model in the file. And theoretically this may be not the only language to express the workflow. Once the file is parsed, we operate on model, not on the language. 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? [1] https://wiki.openstack.org/wiki/Mistral, DZ On Feb 26, 2014, at 7:19 AM, Renat Akhmerov rakhme...@mirantis.com wrote: I don’t see any issues with term DSL (Domain Specific Language). This is really a language which 'workbook definitions’ are written in. Dmitri, could you please provide more details on why you question it? Thanks Renat Akhmerov @ Mirantis Inc. On 26 Feb 2014, at 20:12, Nikolay Makhotkin nmakhot...@mirantis.com wrote: Due to the comment to https://review.openstack.org/#/c/75888/1 there is a quiestion: Do we use term DSL or something else? I think the word 'DSL' is more fit thing that we call 'workbook definition', some text describing workflows, services, tasks and actions. And processing module for this also has name 'dsl'. Thoughts? Dmitri? Nikolay, Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Defining term DSL
On 26 Feb 2014, at 22:54, Dmitri Zimine d...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
