The three dragons and the reverse graft
...a modern-day software fable
6 March 2005--The path to Helix 6 began, innocently enough, with a plan to deliver an OS X version of Helix that had state-of-the-art networking, could sustain a potentially much greater file size than 2 GBytes and would not preclude enabling Helix to reach out into the worlds of Windows and Linux, which, at the time, were features slated for a Helix 7 yet to come.
In a very real sense, a software project is like a tree, in that it has a trunk and branches. Only one branch can be the trunk, identified most closely as the tree itself, the result you are attempting to realize. Branches appear at various stages in the trunk's development. The wood right there represents the state of the tree when that bnanch appeared.
With Helix 5.2 being the trunk, three new branches appeared. The first was where Helix's new TCP/IP layer would grow, which would extend Helix's reach beyond the local network to encircle the globe. The second was where the code for expanding the Helix file structure would grow. It would produce leaves capable of previously unthinkable size, enabling Helix's new world-class networks to park that data in a world-class garage. Finally, the last would be where Helix itself would transition its main functions into OS X.
As each of these three dragons evolved, they eventually had to be slain, or more properly "merged" or "migrated" into the trunk, into the heart and soul of Helix. Think of each branch as a graft, like taking a cutting from a fruit tree and making it grow. This happens quite often and is generally a successful process. But only in software development does the branch come back later to improve the tree. A reverse graft, if you will. Unusual, and frought with danger, because the graft must itself adapt to all that has changed since it split off from the tree, and the tree must, in its turn, adapt to accept the graft. When successful, a thing of beauty is achieved.
The first dragon to be slain was TCP/IP. This became Helix 5.3, 5.3.1, and finally 5.3.2. The second was the 2GByte lizard. At one point, not long ago, our plan was for this product to be delivered to you as Helix 5.3.2. Then we had a change of heart.
For better or for worse, we made some hard decisions in order to get to OS X with all deliberate speed. The first was that people wanting to use Helix Server in OS X would use Helix 6. If not, they would stay in Helix 5.X. Supporting both platforms on the Helix 6 server ultimately would have taken much too long and we already had a perfectly fine server in 5.3.x for that purpose. It made no sense.
Second, we decided that if your Helix collection was approaching two GBytes and you needed the version with more room in it, you'd have to go to Helix 6. There will be no support for files larger than 2 GBytes in Helix 5.X. That was that. Onward and upward.
Finally, as we prepared to slay the third dragon, the one that would put the other two together and move everything forward, we took a brief look at the past and a long hard look at the future.
When Apple shipped System 7, there were a lot of applications that were known as System 7-compatible and others that were known as System 7-saavy. Since we have been in the business of delivering technology as it becomes available, we saw no reason to make you wait for OS X until every little piece of it was totally supported by Helix.
Our primary objective is to make it unnecessary to use ever use the Classic OS again. That begins on the Helix Server. The rest could come along as it began to function. But when we looked ahead to putting the rest of the pieces out there, we came to the realization that having a native Windows RADE or Linux RADE would still take years to accomplish. So we came up with a plan, and we think it makes a lot of sense.
When Client/Server came about, a signficant aspect of the architecture was that the client machines did some of the processing, rather than simply accessing data from a file server. But because computing power was less than what it is today, it made sense to do it that way. Increased network traffice compensated for unburdening the server.
Now that machines are so much faster, more powerful and cavernous in their storage abililties, it's almost more advantageous to do more of the processing on the server. One result is less network traffic. Another is the ability to reach more platforms.
The new Helix Client will be what is known as a "thin client," and it will give us the ability to add Windows and Linux clients to a Helix network served by a Macintosh. This plan will take only a bit longer than it would have taken only to achieve an OS X only Client. But it could still take a year or more to finish it all.