Design Decisions in the Translator

Minimalist approach to design

We have worked hard with the Iguana Translator to put very little functionality within the product itself. This might seem a little counter intuitive but it has many advantages. Have a look at what happens without minimalism.

One advantage is that it will make it easier to upgrade to new releases of Iguana without breaking interfaces.

From experience with Chameleon and Iguana I know that nobody likes upgrading interfaces. This is one of the biggest pain areas with interface engines that causes a lot of aggravation for their users. Every library that is shipped as a core part of the engine becomes point of potential incompatibility where the slightest subtle change can result in major breakages of interfaces. For instance I recall one instance when we modified Iguana in 4.1 to use unicode and the python regex library was changed and the major pain this caused one customer.

Part of resolving that pain is to build in regression testing as a base part of the platform. We’ve made the first step with this by having the environment have sample data associated with each Translator instance. That is very easy to accomplish with the open nature of the Iguana Translator platform.

The second way is that Lua itself is very clean, very minimalist language with very few built in libraries. Those that do exist are very well thought out, mature and will not change.

The third way we can ease the pain of upgrading is by the way we distribute utility libraries within the environment. Because we have built in source control bundled with the product it provides a very convenient safe way to distribute helper libraries. We can put some of them into the initial repository but that’s it.

After the first install the libraries are not updated. We leave it to the user to pick and choose what they need by using resources like this wiki.

Even when libraries are updated the milestone mechanisms in the Translator will help give a lot of protection.

To explain, imagine you have a Channel Foo which uses a library called hl7util. Even if hl7util is upgraded to a new version that explicitly breaks the functionality of Channel Foo, Channel Foo will still work with the last saved milestone, until the point when you try to alter it. At this point your attention is on the interface and so it should be possible to update it.

Doing things this way means as a middleware vendor we can be a lot more adventurous and creative about what library functionality we provide with Iguana since these mechanisms protect customers from upgrade problems.

The environment itself means that it’s much easier to visually understand and debug libraries should they not work.

So for instance we could build nice libraries to do all sorts of interesting things like automatically pulling height and weight out of ADT messages. For handling date/time formats we provide you with a great library that does fuzzy recognition of adhoc date/time formats. These libraries can be improved over time, interfaces polished. New interfaces can continue to benefit from improvements and old interfaces don’t need to broken or changed for the sake of change.

I think this will make people very happy once they understand it.

Next: Subtle changes in libraries can break interfaces

Leave A Comment?