hide all comments

DSM

API Levels: How Low Can You Go?

December 20, 2005 23:02:44 +0200 (EET)

GarethJ asked about MetaEdit+'s extensibility, I answered, and he was surprised, then understood:

[MetaEdit+ has an example of] what I'm going to call external APIs. This type of API lets you talk to some piece of software in the terms of the primitives it deals with (obviously for meta-software such as any kind of DSL Tool that is a bit of a loose term).
Let's then talk about a different set of APIs - I'm going to call them internal APIs. This type of API lets you talk to some piece of software in terms of both the primitives it deals with and the underlying platform primitives it is built on.
If you're building shrink-wrap software, typically you need control down to the level of those internal APIs for a small amount of the time in order to craft the exact feature that's going to give the last ounce of polish to your product.

Gareth is basically right: the MetaEdit+ API supports operations on the models (e.g. add an object), and on the tool (e.g. open a diagram), but not low level platform primitive calls. Of course, the code you write to do the API calls can do what it likes in terms of low level platform primitive calls.

I'm sure Gareth's right in principal that there are low-level platform primitive operations that could be useful in the API itself, in certain situations. Can people provide some examples? Only when we actually have concrete examples can we start to support them well: otherwise we're at the stage where we say "well, people might want to do *anything*!", and that tends to mean we don't yet really know what this area is all about (and that's not a dig at Microsoft).

We at MetaCase definitely have a different emphasis from Microsoft, in that we envisage each customer software development organization building their own modeling language. Microsoft maybe think that might be possible, but seem to be emphasizing more that a third party ISV or SI would create a modeling language for a broad domain, and then sell it to customer software development organizations. In that case there would be significantly more users for each modeling language, and hence it makes more sense with a tool where building a modeling language takes several times longer, but which allows you to code basically what you want.

Obviously the ideal tool would be as fast and powerful to use as MetaEdit+, and have its maturity, but also have the extensibility of Microsoft's DSL Tools, without crashing into the customization cliff. It should however run on all platforms like MetaEdit+, but be tightly integrated to Visual Studio, Eclipse, and vi. And be free, with complimentary commercial support. But I digress...

Comments

nvyEayOG4C

[nvyEayOG4C] February 26, 2006 23:13:28 +0200 (EET)

xSX4V70yDPm eh6jfntciysCS fOiL2AWag5