An open, royalty-free, formal standard would allow anyone to implement it unencumbered by concerns as to whether the definition of a specific feature or function violates a copyright or patent. [Of course, the implementor would need to ensure that their specific implementation was clean with regard to IP, but a standard would ensure an unencumbered functional specification.]
I believe in open standards developed by open processes. The GT.M team was an active participant of the last set of MUMPS standards and of ones before it. But for standards to be meaningful, the process must be open, multiple conforming implementations must exist, users must use standard features in preference to non-standard alternatives. I am not convinced that the MUMPS user community, other than perhaps the VA, is ready to use standard features in preference to non standard features. But I am eager to be persuaded that the MUMPS user community, and at least one other vendor, are ready for the next round of standards. >From a standards perspective, Greg's proposal is affected by one weakness that MUMPS has in comparison to C and Java. In C, there is a clear distinction between the C language syntax and libraries that implement APIs, and C language syntax is standard. With MUMPS, this is not the case. However, let me throw in something to think about. Let's conceptually separate the MUMPS database from the MUMPS language. It seems to me that if we define a callable API for the database (one that includes not just global variables but also M transaction processing and M locks), allow access to the database via this API, and allow code in other languages to freely call back and forth to and from M code, then an application like VistA can use other languages as well as M (not just C, but also languages like Perl that have much of the expressive power of M but with more modern features like information hiding). New modules can be written in the most appropriate language, but can freely interoperate with modules in other languages. MUMPS has had limited acceptance in the world at large outside health care (I assure you that although we are successful doing it, and despite the extraordinary scalability and robustness that our banking application, Profile, derives from GT.M, every sale of a Profile license has a phase akin to rolling a full barrel uphill when we have to get the customer to buy in to M). The MUMPS database has much to offer, and separating it from the language, and opening the MUMPS environment up to Perl, PHP, Java, etc. might be what it takes to allow MUMPS to break out of healthcare - and in the fullness of time, to be more accepted within health care. Instead of being called legacy technology, M could be called heirloom or heritage technology! Back to M standards: Fidelity cannot commit to implementing an unspecified standard that doesn't exist yet. But if there is a standards development effort, I will participate enthusiastically if there is broad involvement and a community commitment to it. I'm sorry to have rambled, but the issue is complex and multi-dimensional, and there are no easy solutions. -- Bhaskar On Wed, 2005-11-30 at 11:26 -0600, James Gray wrote: > Sounds good. What do Fidelity and Intersystems think of the idea? > > I was wondering if we could have a defacto standard. Could or would > GT.M. > be able to implements some of the enhancements in Cache? Would that > violate > Cache copyrights? Would Intersystems applaud or condemn such a move? > > Jim Gray > > ----- Original Message ----- > From: "Greg Woodhouse" <[EMAIL PROTECTED]> > To: "Hardhats" <[email protected]> > Sent: Wednesday, November 30, 2005 10:10 AM > Subject: [Hardhats-members] A conservative option: MUMPS Standard > Library > > > > I've been thinking about how best to address the various platform > > issues that continue to come up on Hardhats. There seems to be a > strong > > consensus that supporting the standard is the right course, but it > is > > equally clear that there are many small detailss in which MUMPS > > platforms differ (details that Kernel tries to encapsulate), and > > fundamental pieces of functionality (like UDP support, asynchronous > IO, > > etc.) that are not available at all. > > > > Many languages (such as C or Haskell) address this issue through a > > standard library. Those of you familiar with C, for example, will > know > > that printf() and scanf() are not part of the C language, but they > are > > included in the standard library. I propose that we define a > standard > > library that is independent of the existing standard, and that we > > include a simple syntactic extension (say S X=$|OPEN(...) to call > OPEN > > from the standard libary) to provide a consistent binding. We could > > perhaps call the pair MUMPS 1.1 and MUMPS Standard Library 1.1. An > > important beinefit to this approach is that it would allow for code > > that is optimized for a particular platform (e.g., in the area of > job > > control) while remaining standard. > > > > === > > Gregory Woodhouse <[EMAIL PROTECTED]> > > "Interaction is the mind-body problem of computing." > > --Philip L. Wadler > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log > > files > > for problems? Stop! Download the new AJAX search engine that > makes > > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
