> > On Mon, 2005-08-22 at 19:50 -0500, [EMAIL PROTECTED] wrote: > > > > > > One of the requirements for an IETF (Internet Engineeering Task Force) > > > standard is that there be at least two interoperable implementations > > > with different code bases. Obviously, the IETF standards process isn't > > > directly relevent to VistA, but I think the principle is a good one. To > > > be considered stable, I think VistA should be required to run on at > > > least two independent MUMPS implementations, and they should be able to > > > communicate (e.g., via TCP/IP). For example, it wouldn't do if Mailman > > > on one platform was unable to exchange mail with a peer running on the > > > other platform due to idiosyncrasies in I/O or socket handling. > > > > This sounds like a fine idea. > > Do you think the operating system that the M implementation is > > running on should be taken into account? That might be a way > > of forcing two different codebases for the stuff that isn't > > in the M implementation, such as the TCP/IP stack... > > > > David Whitten > > What? Are you suggesting that a rewrite of core OS functionality be > rewriting into MUMPS? > > Ruben
Sure, we should write one version of the Operating System in Lisp, one in MUMPS, one in FORTH or POPLOG, one in ASM or C, one in Prolog, one in Modula-3 or Ada, one in Perl, one in ML, and one in APL. Then we run them in parallel and at least five out of nine wins. These languages are chosen because they require totally different mindsets when programmed, and make different assumptions about the capabilities provided by the base system when writing code. So the code would be almost guaranteed to use different algorithms. This would be the most redundant and fail-safed method, methinks. Actually, I was just thinking that if you have a MUMPS implementation, it will not provide directly all of the services that a MUMPS program will use when running. These services typically include such things as virtual memory allocation, disk buffering, TCP/IP stack, interrupt processing, I/O device handling, interprocess locking, maybe even B-Tree code. Thus if we want VistA to be truly portable, we should consider not only that the M implementation must be different, but that the other code should be different as well. David Whitten (713) 870-3834 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
