> So, gang, can we brainstorm up a solution that meets our needs AND is > sanitary and safe for Apple to implement? (It would be REALLY BAD to > solve this problem and create a bigger problem in the process. :-)
I'm more of an onloooker than a member of the gang, but I don't know, Rich. In order to handle version transitions cleanly, the run-time library has to know which version of which modules it's supposed to have, and the programs which link into it have to know which version they want. Java can almost handle that. Is perl there yet? Can a program go to the perl library and say, "I need to link to HTML::FormatText, any version between n and m," and expect to be understood? And, in order to handle transitions transparently, more than one version has to be present. The stock version of the system would claim compatibility for p years, and the library would provide every major version current to those years for each module supported by the stock system. Program x wants HTML::FormatText version n, and program y wants HTML::FormatText version q, and they want them at the same time. I can see how it could be done with namespaces or something like that, but can perl handle that yet? And you'd want whatever is handling the library to allow a tech or the end-user to add non-stock modules and versions, of course, with some sort of a wall between more trusted code and less trusted code. (Ultimately, you'd want to have the system automatically request modules over the network, I suppose, but that would require tighter security than we can expect for the next several years.) Some of that could be partially implemented by hand, by keeping multiple versions of perl around and warning all script writers to avoid the generic /usr/bin/perl in the shebang line, opting for, for example, /usr/bin/perl-5.6.0, instead. It might even help to have something like /usr/bin/perl-5.6 pointing to the latest stable version of 5.6, and perl-5 pointing to the latest stable perl 5, so that users could pick a little loosely. Sloppy, but maybe better than nothing. Maybe not. Hmm. Now we now what to do with those 120G drives they're selling so cheap these days. :-P Then, there's the question of all the scripts that somebody needs to either test exhaustively or examine closely enough to know whether or not the shebang line can just be edited when it's time to leave an old version behind. And there's also the tangle of security holes that people would tend to leave sitting around on their hard drives. It's a problem that needs to be solved, of course. -- Joel Rees <[EMAIL PROTECTED]>
