[ovirt-devel] Post: External DSL for API Specification in oVirt

Arik Hadas ahadas at redhat.com
Tue Oct 25 11:01:27 UTC 2016


----- 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 <ahadas at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 



More information about the Devel mailing list