Hi Arik, nice article. I do agree that external DSLs are useful, but I have (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.
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
