Blog

It’s the survival of the fittest game, that stuff that happened to the dataports. You know dataports? That class of NAV objects that’s used to move data back and forth in text format?

It’s really funny what has been going on with them lately. They evolved, then degenerated. Today, they are an endangered species. A release or two, and they might be gone for good. Just like dinosaurs.

Dataports have been used for import and export in NAV since forever. Text was all they could do, though. Yes, variable or fixed, that was your carte du jour, but it was still text, only text, and nothing but the text.

Then in version 2.60 evolution happened. Dataports evolved to support XML. Since XML natively supports hierarchical data models, something not easily represented with a flat text file structure, with XML support the dataports also got the indenting and data item reference linking functionality—but only for XML files!

The evolution didn’t stop there; with version 4.0 it went on, and a completely new species sprang: XMLport. Obviously it’s purpose was to do the same as the dataport, only with XML. The new kid on the block was more powerful than its elder brethren: it was able to stream data in or out directly to and from stream objects, allowing it to communicate with a lot more than mere files.

At the same time, dataport population was decimated, and most of objects that were previously dataports evolved into new, more versatile and robust XMLports. The measly six dataports remaining in the W1 release of NAV are not of any particular use. I bet this blog’s monthly traffic that you hadn’t used any of them for real.

So evolution took dataports their XML support away, but it wasn’t totally cruel, and it left over some rudiments from previous versions: even though dataports couldn’t handle the indented data items anymore, DataItemLinkReference, DataItemLink and DataItemIndent properties remained. A token of goodwill, or something of the sort, probably.

Funny things happened if you tried to put these rudiment properties to work, and actually indent data items. As soon as you compiled or saved the dataport, it complained:

There was absolutely no way to configure this file format for evolved dataports, yet they longed for it. The nostalgia lasted for quite a while: version 4.0, 4.0 SP1, 4.0 SP2, 4.0 SP3, then 5.0 and 5.0 SP1, all retained the functionality to indent data items, only so they can complain about not being able to handle XML anymore. Weird stuff.

But the evolution, which was obviously determined not to stop yet, sported its sarcasm and caprice to the fullest with NAV 2009. In this version, XMLports evolved, so instead of handling only XML, they are now capable of handling text files as well. Fixed or variable, your choice. Now that XMLports do both XML and text, why do we need dataports?

And indeed, dataports continued their death march. The RoleTailored client of NAV 2009 can’t even run dataports, it can only do XMLports. In NAV 2009 the relic property DataItemIndent died away as well, and so did the buttons for indenting data items. But the other two properties remained, those that were used for reference linking. They remained, but they are doing nothing (or nothing useful, to be totally fair).

It’s hard to tell the evolution’s wily ways, but with dataports nearly extinct, who’s the first to give in: dataport reference linking, or dataports themselves?