marcs@SLC.COM (Marc San Soucie) (11/14/90)
Vania Joloboff asks about compatibility in MOTIF 1.2: > OSF for Motif 1.2 wants to reach binary compatibility with 1.1, > which means a 1.1 application can be relinked with 1.2 library > and run without recompiling. Call me a heretic, but I don't think this is an absolute must. Depending on the magnitude of the changes required, some degree of recompiling and even recoding (yes, even recoding) is reasonable, so long as two conditions are met: 1) The changes produce some added value above and beyond percentage-point performance gains or interface cleanups. 2) You OSF types *document* the changes in a genuine, real-life, ASCII-encoded PS-roffable Official OSF MOTIF 1.2 Upgrade specification. You dropped the ball big-time with MOTIF 1.1, in that you provided little or no serious change documentation. The README file described some changes, and hinted at others, but determining a code upgrade path was left to the reader as an exercise. We are all still suffering from it, as we fuss about with our code trying to figure out how to use XmProcessTraversal instead of XmAddTabGroup, and other such inconveniences. Yes, maybe I'm spoiled, but when I produced subroutines as a product, I produced documentation for them, and changes to the interface and behaviour always had to be carefully notated, or I'd be punished. Our ability to punish OSF is limited, so we must resort to pleadful entreaty. Please, please, document your upgrade path in infinitesmal detail. So anyway, 1) If you can manage with just a relink, great. 2) If you need some recompiling, okay. 3) If you require recoding, make it worthwhile, and tell us how. > There are issues concerning 3). We expect to gain performance in 1.2, > particularly save memory space. But some performance can be gained > only by changing the private data structures used in the *P.h files. I would like to echo Morgan Stanley's request for some documentation for the MOTIF-compatible widget writer. Fishing the technique out of the source code is a slimy way to do business. Build routines and macros, document them, and you'll never have this problem again. Interfaces are meant to be hid behind. Build a good one and nobody will knock it over to get at you. Marc San Soucie Servio Corporation Beaverton, Oregon marcs@slc.com
korp@atlantis.ees.anl.gov (Peter Korp) (11/14/90)
In article <9011132152.AA24980@servio.SLC.COM> marcs@SLC.COM (Marc San Soucie) writes: > >Call me a heretic, but I don't think this is an absolute must. Depending on the >magnitude of the changes required, some degree of recompiling and even recoding >(yes, even recoding) is reasonable, so long as two conditions are met: > > 1) The changes produce some added value above and beyond percentage-point > performance gains or interface cleanups. > > 2) You OSF types *document* the changes in a genuine, real-life, > ASCII-encoded PS-roffable Official OSF MOTIF 1.2 Upgrade specification. > No! No! NO!!!! IMHO recoding is not an option. A recompile, okay. But if I have to go back and support routines I wrote just to make them work with the new toolkit, I will move to a "more stable" toolkit. I can have clients recompile, but damned if they are about to go through the hassle of recoding or the pain of paying me to recode it. >You dropped the ball big-time with MOTIF 1.1, in that you provided little or no >serious change documentation. The README file described some changes, and >hinted at others, but determining a code upgrade path was left to the reader as >an exercise. We are all still suffering from it, as we fuss about with our code >trying to figure out how to use XmProcessTraversal instead of XmAddTabGroup, >and other such inconveniences. > I whole heartedly agree. How were we ever supposed to figure out what was going on? Worse yet we did not have the source to look at and see what was up. Please document your next release! > > Marc San Soucie > Servio Corporation > Beaverton, Oregon > marcs@slc.com Peter