While such rogue actions are possible in M, there are other constraints besides those imposed by the language environment. In VHA before code is released it is examined using tools such as XINDEX (as well as direct code inspection) by individuals other than the original programmer. The code is also open for all to see. And the original programmers (are at least supposed to) have security clearances and are expected to act honorably and follow policies and standard operating procedures. Of course, human error can and does happen and using good programming practices can help keep those to a minimum.
Bypassing the "public" entry points/API's is sometimes permitted when such things as performance or timeliness of being able to respond with new code become issues. I've heard no one express the belief that "developing new modules that build on what we've learned from VistA ... which interoperate with the existing product to the extent that is possible [is] dismissed out of hand as being nothing more than a euphemistic way of speaking of wholesale abandonment of the technology." But I HAVE heard others say that developing in such a manner should not be undertaken because it "will just let developers keep doing what they've always been doing." Which always struck me as being absolutely false (and in fact rather arrogant ... the one speaking is willing to change but other developers are not). I believe most developers embrace things that are more efficient and more secure. And by the way, only when coding "by the rules" are OLE/COM objects (or any other components) inviolate. Code with enough authority at run time can do anything to such objects. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Gray Sent: Wednesday, May 25, 2005 8:32 AM To: [email protected] Subject: Re: [Hardhats-members] Question on updating the database I may be misunderstanding something, but isn't the main problem that there is no way to force encapsulation in Mumps. Even if developers create well designed public entry points/API's for a package, it is always possible for a Mumps programmer to bypass the official method for using the entry points for a package. It seems the problem is inherent to Mumps, not VistA. Jim Gray ----- Original Message ----- From: "Gregory Woodhouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, May 24, 2005 9:54 PM Subject: Re: [Hardhats-members] Question on updating the database > You're absolutely right. There are many serious problems with VistA as it > exists today, of which this is but one. What I find incredibly > frustrating (not to mention foolish) is that in the name of advancing > VistA we so often turn a blind eye to these types of issues, or even deny > that they are real problems. I can understand not wanting to see it > abandoned, but ignoring issues such as this is not the right way to > advance the technology. I believe we would be much better off developing > new modules that build on what we've learned from VistA (and that's a > LOT) and which interoperate with the existing product to the extent that > is possible. Unfortunately, this is an approach that tends to be > dismissed out of hand as being nothing more than a euphemistic way of > speaking of wholesale abandonment of the technology. > > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "Before one gets the right answer, one must ask the right question." -- > S. Barry Cooper > > > On May 24, 2005, at 6:28 PM, Kevin Toppenberg wrote: > >> I hear you. My point, though, is not that tedious >> work is necessary. But rather that one has a fragile >> system indeed if one rouge programmer can cause havok. >> When I work with the Microsoft Word OLE/COM object, >> there is NOTHING that I can do to that code that will >> harm that code. *IT* controls what happens within its >> boundries/domain/module. >> >> VistA/M seems to have essentially two levels of >> security. Programmer level, and then user level. >> Once someone has programmer access, they can do >> ANYTHING. This can be good and bad. >> >> I just had a flashback to Marty quoting that >> programming with other structured languages was like >> holding hands with your girlfriend at the Sunday >> social. While M was like having sex with your best >> friend's girlfirend on the back of a motorcycle. i.e. >> wild, dangerous, and perhaps a lot of fun. >> >> LOL! >> >> Kevin >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
