----- Original Message ----- > Hi Arik, > > nice article. I do agree that external DSLs are useful, but I have
Thanks! > (long-standing) objection to inventing new ones, especially in an area > of SDKs. I still feel we should have adopted something that is (at > least close to) industry standard - Swagger [1] or maybe Blueprint > [2]. We would get all the tooling and SDK generators "for free". > Inventing a new DSL that only we know about means we have to maintain > all the tools ourselves. Right, I do not claim that the proposed external DSL is the ideal language, others including existing ones can (maybe even better) fit. I'm not familiar with Swagger and Blueprint so I cannot address them specifically, but I guess the general trade-off will hold: by using languages that intend at being reusable in multiple projects you can leverage their implementation and tools that are also typically more mature but would typically lack project-specific things like the ability to define a field with predefined values as our status of documentation (and then the question to be asked is if we actually need such project-specific things). In a paper that is currently in review I argue that chances that ordinary DSL would be reusable as third-party language in other projects are significantly higher than those of the reusability of a domain-specific aspect language. Of course, if that is the case then a third-party DSL should be considered in light of this trade-off. > > I agree with the general points though, it is very nice when the > boilerplate is inferred from the sources. It reduces overhead and the > chance of (coding) bugs. > > On a side note: > > The separation of the API definition jar from the rest of the engine > source code was a good move. But on the other hand, the repository > separation of the definition from the engine implementation was not so > great :( We lost atomicity and easy revert capabilities (for example > when the API definition version requires two new features, but only > one is implemented till deadline) and increased the overhead. > > > [1] http://swagger.io > [2] https://apiblueprint.org/ > > On Tue, Oct 25, 2016 at 8:07 AM, Arik Hadas <aha...@redhat.com> wrote: > > Hi All, > > > > Last month I attended Juan's session on the recent changes in RHV API. > > I wrote a post on how I believe it can be enhanced by using an external > > domain-specific language rather than the internal domain-specific language > > that is used today: > > http://ahadas.github.io/dsl-for-api-spec-in-ovirt/ > > > > Your feedback is welcomed, > > Arik > > _______________________________________________ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel