The Tale of Components C and D

AKA: A Brief History of Fire (with apologies to Steven Hawking)

26 May 2006--About five months have now passed since the last edition of The Latest Word. In spite of the prolonged silence, quite a bit has happened at QSA, but some of it is just blindingly dull to talk about and most of it has been difficult to discuss in the context of where things are going.

The hardest part of getting these updates out has always been figuring out where to start. This time, we figured out where to start back in February, but as work on the narrative progressed, important milestones in the march to get the rest of our products to macOS were achieved and a great deal of what we wanted to convey suddenly became very dated.

Before we knew it, we had enough material to produce a raging bonfire of information, but we thought it would be smarter to break it down into a series of ‘campfires’ that you can draw close to and warm your hands by. So here we go.

Keeping the flame alive

On one of our FAQ pages, chief engineer and our own personal Merlin, Larry Atkin, is identified as a ‘Keeper of the Helix Flame.’ If you’ve had any lengthy association with Helix, you know Larry is actually one of the four pyrotechnicians who fanned the original ‘spark’ that became Helix 1.0, inventing this particular brand of fire back in 1984. Two of the four, Jonathan Schneider and David Harmon are now gone from this world; the fourth snuck into our web store late one night and quietly bought himself a new copy, perhaps thinking we wouldn’t notice. (We did. Thank you.)

The names of the Keepers have usually appeared in an ‘Easter Egg’ within Helix, as they do now. If you remember where it used to be, it’s still there. (If you haven’t ever seen it… keep looking.) And if you have some free time be sure to check out the more colorful version found in Helix Server.

Being identified as a Keeper of the Flame is surely a great honor in this small community, and when the Helix world starts expanding again, the depth of that honor will expand with it. Today we pause for a moment to give credit where credit is due and to say that all who have contributed above and beyond the call of duty to the survival of Helix are part of a new group of Keepers of the Helix Flame. Those people (perhaps you, reading this right now, are one of them) who have carried the Helix torch on to this critical place in its development deserve our thanks. It is our sincere desire to one day be able to say thank you with more than just words.

Even if you are not a ‘Keeper of the Flame’ — maybe you’re one of the thousands who have pitched in by purchasing an upgrade, thereby contributing fuel to keep the fire buring — you surely have your hearts in the right place even as you ask us the following questions seemingly without end: ‘Why on Earth did you do Helix Server before RADE? Don’t you understand your own market? Don’t you know who your users are?’

Our reply to that question has consistently been ‘RADE is absolutely our top priority, just not our first priority.’

Taken on the face of it, that may sound like double-talk. What we’re trying to say (in spite of what anyone might believe) is that we care more about RADE than anything else, but until we’ve done what must be done, RADE simply has to wait. We know that until RADE is in macOS, Helix is still a product that requires Classic. That’s a place we don’t want to be anymore, and with Apple rapidly moving their entire product line to Intel chips, it is a place we cannot stay for much longer.

Where there’s smoke, there’s fire

A recent conversation with an enduser convinced us that an understanding of what was called, some years ago, the Helix ‘paradigm,’ might go a long way to making our reply more clear. If that word has you scrambling for your dictionaries, the definition is: ‘a worldview underlying the theories and methodology of a particular scientific subject.’ In other words, we’re about to give a little lesson in how Helix works on the inside.

So why did we move Helix Server to macOS first and why have we publicly stated that Helix RADE will be the last product to macOS? The answer to both questions is in the paradigm, which we’re about to explain. Once you understand what Helix is, you will see that the path we are on is the only logical path we could take. And by understanding, we hope you will be more inclined to help us keep this flame burning.

So let’s get technical for a few minutes. But not too technical. Hopefully just technical enough for you to see it from this side a little more clearly.

Helix is made up or four distinct components:

Components B and D should be clear: if you’re a Helix Client or Engine user, you use Component B every day. And if you work with Helix RADE, you’re already intimately familiar with Component D (as you should be with Component B).

But what about those other parts?

Component A is the underlying database — the part of Helix that actually stores the data, updates the indexes, does all the things required so that the user can work with the data using Component B. You never see it, but it’s what makes Helix a database and not a word processor or spreadsheet. Without Component A, Helix wouldn’t be able to store the data you enter or retrieve records when you ask to see them.

Component C also needs some an explanation, since that tends to be the hardest part of the whole paradigm to understand. When you are using Helix, you enter data on a View (part of Component B) and you press the Enter key to store that data (in Component A). But how does the data get from A to B? In other words, when you press the Enter key, how does your input get translated into data that can actually be stored? That’s the job of Component C. When you open a list View, Component C takes the raw data from the database and hands it to the View so it can show you a list of records.

For Helix Client/Server, this ‘pipe’ is most obvious: it runs through the Ethernet wiring that connects the Macs in your office. But RADE and Engine also have this pipe, it’s just hidden inside your computer. In other words, whether a View is presented by Helix Client, Helix Engine, or in the User Mode of Helix RADE, the View always recieves the data from the underlying database using the same ‘Component C’ mechanism. That’s the paradigm.

Armed with that information, we can now map out which components go into each of the ‘Big Four’ Helix products: Server, Client, Engine and RADE:

The work we began in December of 2002 was to modernize these four distinct code components so they could run in macOS. Since Apple has thrown the ultimate curve at us during this process, that work also now includes getting the code to Universal Binary. But from the information in this chart, you can see that Components A & C are already done, which is why you now have a Server that runs natively in macOS.

Component C is required for all of the Helix products, so that absolutely had to be done first, and we delivered that to you in 2004, back in Helix 5.3 . By the time that was done, some of our users were in crisis mode: Apple was no longer making Macs that would boot natively into OS 9, and Helix Server would not run reliably in Classic Mode. So we turned our attention to Component A and delivered Helix Server for macOS in 2005.

By then, we knew the Intel-based Macs would soon be arriving, so we turned our attention to the remaining components. In a previous edition of The Latest Word, we alluded to the fact that Helix Client and Helix Engine are scheduled to be next, followed by RADE. Looking at the above chart, you should be able to understand why: Components A & C are done, and we’re now working on Component B. As soon as that is macOS native we will have two more macOS native products: Helix Client and Helix Engine. We’re making progress on that daily, and you can track that progress (along with our work on ‘Universal Helix’) on our Xcode Transition Page

The chart also illustrates another fact: Component D is required only for RADE/Design Mode. It is not needed for any of the other products. After Server, the single most often requested product by our customers is a macOS native RADE, but as you can see from the chart above, even if we had dedicated ourselves to getting Component D to macOS, we would still have had to do A, B & C before we could ship RADE. If we chose that path, we would not have any products (no macOS Server, Client, or Engine) until we finished all four of the Helix products.

Hopefully this explains why the course of action we are taking is the only technologically sane one available.

A controlled burn

Since June of 2002, there have been four new releases of Helix, each with significant improvements over previous versions. Since we’ve been in control of the Helix development schedule, we have opted to put those improvements into your hands as soon as they were ready to use, and not hold them back for a ‘big splash’ release that would garner lots of attention. We have consciously avoided the so-called limelight because we don’t want it shining too brightly on our well-documented shortcomings.

In the beginning, we took this approach in part because we did not know what plans there were for Helix and did not want any of the work we had done to be lost. As everybody now knows, the Helix assets were sold in 2004 and we were fortunate to be able to purchase the Helix source code and maintain the continuity we had established while working in the shadows. And while we continue to follow that model, this phase of the evolution of Helix is finally, happily drawing to a close.

At this point, those among you who use only RADE are probably throwing your hands up in despair, thinking you’ll never see your Helix collections running without having to launch Classic. You are surely unhappy that the product you use (and love) is last in line. But despair not, for we have good news for you, and it comes from a place you might see as unlikely: Helix Engine.

When Helix Engine macOS ships, owners of Helix RADE 6.0 will be able to use their RADE 6.0 keys to register it. If you are not familiar with Helix Engine, it is essentially the User Mode side of Helix RADE. That means that for your day-to-day data entry work, you’ll be able to run your collections in macOS long before we get the finished native RADE into your hands. You’ll still need to hang on to Classic to make Design Mode changes to your collections, but most of the time, you’ll be able to kiss Classic goodbye.

So if you’re a Helix RADE user who has never worked in User Mode (formerly known as ‘Custom Mode’), now is the time to upgrade your Helix RADE license to 6.0, open up your copy of The Helix Reference and learn how to create custom users. If you’ve never used RADE in User Mode before, if you work strictly in Design Mode with the collection, relation and icon windows all over the place, you're missing out on the part of Helix that puts it all together. If you're missing that part, discover it today and you’ll wonder why you waited so long!