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.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 <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 > > -- Best Regards, Nikolay
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev