Next Up Previous Contents Index
Next: Breaking the 3D Up: The Portable Data Previous: Compatibility status summary

Upper and lower case

I have done nothing in this project to resolve the issue of case conventions for file names. I consider this issue so controversial and politically charged that I'm not yet ready to step into it. I hereby submit my recommendations for comment. Each system will define a tag in SYSTEM.H called CASECONV. It shall be set to one of four values:


CCMONOU      System is monocase and uses upper.
CCMONOL      System is monocase and uses lower.
CCULU        System uses both cases and prefers upper.
CCULL        System uses both cases and prefers lower.

When a system writes a drawing database, it stores its CASECONV setting in the drawing header. This is referred to as the ``case convention of the sending system''. When a system reads a drawing, if it was created on a system with a different case convention, it processes file names in symbol table entries based upon a matrix of the sending system's case convention and its own. If the receiving system is monocase, file names in symbol tables are not translated, but FFOPEN and its clones translate all file names to the receiving system's case convention before submitting them to the system. If the receiving system uses both cases and the sending system was monocase, names in symbol tables are translated at read-in time to the preferred case of the receiving system. The names are then used as modified, without further modification by FFOPEN. This is asymmetrical and impossible to justify except by convincing yourself that this is the best approximation to what's best for the user.

 

My throat was feeling a little dry after such a lengthy dissertation. I got up to refill my glass. When I walked back to my chair, Galt was flipping through the listing of SMIO.C next to the Sun. He turned to me and said, ``Why do you do this? Here you are in the middle of the night struggling trying to trick this megalith of software into threading its way around incompatibilities between computers that aren't even of your making.''

I replied, ``Differences in products are a consequence of their rapid evolution in a free market. Incompatibility is the price of progress''. John Galt was speechless for at least 12 seconds.

He rose and said, ``Join us. You weren't ready in 1967. Now, in 1987 you should see that you're struggling to make money in a world where the money you make is taxed away and handed to defence contractors like Lockheed and McDonnell-Douglas, who turn around and compete against you with products your taxes paid to develop. While so many others are sleeping, you labour to produce intellectual property, then you listen to others lecture you on their ``right'' to steal it. Can't you feel the circle closing? Can't you see that this can't go on? Why not hasten the inevitable and pave the way for a brighter day? You should drop out, or work to hasten the collapse.''

I looked at the DIFFs of my portable database code. I said, ``After this project, I can't help but feel that hastening the collapse would be an exercise in supererogation.''

Galt shrugged. He sat back down and said, ``Your time hasn't yet come. I try to talk to people when they'll see the issues most clearly. I try to find the times when they see what they're doing and begin to wonder why. I'll be back. It may be in two days, two years, or maybe twenty years.''

We talked for an hour or so about old times, common friends, and shared interests. He left as the sun was rising.


Next Up Previous Contents Index
Next: Breaking the 3D Up: The Portable Data Previous: Compatibility status summary

Editor: John Walker