I see. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Self Sent: Monday, October 17, 2005 1:46 AM To: [email protected] Subject: RE: [Hardhats-members] CPRS alternatives (was: Cost to convert CPRS to Java
Roy Gaber wrote: >My wish is that we all choose our methods of delivering quality applications >to the user and not feel like we have to defend why we chose how we >accomplished it. These ramblings remind me of the MAC/PC wars of days gone >by. My intent in the previous message was not to attack anyone but to explain some of the things I know or think I know and to elicit explanations and clarifications and perhaps corrections from people like yourself based on your knowledge and experience with technologies and working environments that are at least in part very different from the ones I know. I am not so much interested in why you chose the technology that you are or have been using as in how it is different or similar to the stuff I am familiar with, how it seems to be working, where you think it is going, and how it all relates to the longterm viability of VistA and related healthcare information systems. I seem to recall that you were/are one of the developers of CPRS. Is that correct? Do you you have much familiarity with the server side of CPRS and VistA? How many people are or have been involved in the development of CPRS? How many people do you know that have a significant depth of knowledge of both server-side and client-side aspects of CPRS? What sort of development is ongoing or planned for CPRS? Same questions regarding the Java based replacement for CPRS? >I am not pointing the proverbial finger at any one individual or group; I am >simply stating that I am tired of reading about why this language is better >than that language, and this method better than that method. Surely, some methods and environments clearly ARE better than others, even if the reasons aren't apparent until years after we have made a choice. I would think that discussion of how and why is potentially quite important. Perhaps we don't have sufficient overlap in our knowledge of similar technologies to have a meaningful discussion. I hope that's not true, but it seems to me a worthwhile thing to know of itself. I am working under the assumption that there are still technology decisions to be made by some of us and that there is room for multiple solutions. In particular, I am hoping to interest a small number of individuals in learning about and working on the development of Open Source web based tools that can interact with and enhance VistA and other MUMPS based information systems. >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Jim Self >Sent: Sunday, October 16, 2005 11:16 PM >To: [email protected] >Subject: RE: [Hardhats-members] CPRS alternatives (was: Cost to convert CPRS >to Java > >David Sommers wrote: >>From my perspective, web apps (unless you're talking ASP.NET) still >>require a lot of "goo work". Coding in classic ASP, PHP, Python, and >>Perl requires a lot of [what .NET calls] View State management. Stuff > >Could you give a little more detail to clarify your perspective for me and >to help me >clarify mine for you? I am not at all familiar with Microsoft's ASP* and my >knowledge of >the "classic" web app types that you mention is limited and based pretty >much entirely on >reading about them rather than using them. > >We (VMTH Computer Services, UC Davis) started working with the web directly >from MUMPS as >an outgrowth of VMACS development before ASP or PHP were even conceived and >we (did not >begin to learn anything about Perl or Python until much later, after we had >begun to >explore migrating our servers to Linux. We have quite a few tools developed >from a >MUMPS-to-web perspective that may not have close equivalents in these other >toolsets. > >>like, entering a string into a text box. You have to code in the form >>post, validate it, if an error, show the same HTML and then put in >>(yourself) the original text with a message explaining why it wasn't >>accepted. > >I am not quite sure what you are contrasting here. Certainly, there is a >need to define >forms one way or another and to validate inputs in what ever way they are >received by a >server and for the server to return error messages and other feedback. > >>In real world apps, you balance the thick and the thin. There are >>still, arguable, a ton more that can be done in thick than in HTML. > >What aspects of a hospital information system do you think are beyond the >realm of Firefox? > >>And that is why not all my projects are on the Web. I have a mixture of >>both. This is a perfect example of using the best tool for the job. I >>would argue that it would be quicker to write a fully functional and >>interactive EMR in some thick language than via a web browser. > >It's not clear to me why (or if) that would be. If the EMR is based on VistA >or other >MUMPS data sources I would expect the thick client solution to require >orders of magnitude >more code and a large staff of programmers dedicated to the client-side of >development in >addition to those who work with the server. > >One reason that I would expect a MUMPS-to-Web solution to be easier to >develop is that it >could readily take advantage of metadata to define the user interface. For >instance, input >forms could be generated on-the-fly and filled with data and behavior based >simply on >file, iens, and a list of field identifiers. > >Is that a capability of CPRS or its envisioned Java based replacement? > >>Jim, it sounds like the software delivery mechanism was a key point in >>your tools and platform decision, so that's the tipping point for your >>situation but not all situations are alike. Each developer or project >>will have to follow an analysis process. > >Actually, it's more the integration of the information system into a >coherent whole, >defined and managed from a unified center that interests me - plus a strong >desire to >avoid vendor lock-in and vulnerability to security flaws in proprietary >products from >vendors with a long history of ignoring essential security concerns for >networked systems. > >I also want to avoid and help others escape from the fragmentation of >systems development >that seems to be a consequence of the thick client paradigm. I believe that >this presents >a substantial impediment to the long term evolution and development of >complex information >systems like VistA. > >I have had very little contact beyond discussions on this list with >programmers involved >with CPRS development, so perhaps I am wrong, but it seems to me that there >is a growing >chasm between those who know and can program the MUMPS side of VistA and >those who know >and can program the thick clients of the RPC interface. > >Please correct me if I have misinterpreted. > >>In comparison, most EMRs are not delivered via the web browser. Not >>saying they're right or wrong, it's just that the decision isn't so >>cut-n-dry. >> >>I'm not going to speak for all the M programmers out there - but to >>build CPRS in a pure web browsing experience would be somewhat drastic. > >??? Why drastic? They don't have to throw out their expertise with M and >pick up a new >language with a long learning curve before they can be productive. Most >applications can >be programmed entirely by: > > 1) examine MUMPS variables holding input values > 2) call MUMPS functions to access the database and to > transform data values into internal or external forms > 3) WRITE output to the home device. (no READ or USE commands required). > >Actually, it's even simpler than that since WRITE is not even required. An >application can >simply SET the value of the content to be returned into a local variable. > >>And there's key pieces that may not fit so well, like what about >>diagnostic images or EKG readings, etc. > >Most images, diagnostic or otherwise, are easily handled in a web interface >with >appropriate server-side tools. Imagemagick, for instance, does a large >number of image >transformations, including resize, rotate, crop, sharpen, color reduce, >contrast >adjustment, type conversion (such as from DICOM to JPEG), etc from simple >command lines. > >Diagnostic images for the imaging specialists in our shop currently require >special DICOM >viewing stations, but everyone else can get along quite well with more >modest hardware (at >least for now) and web based software. > >>Eclipse, .NET, and Borland have many programmers in a drag-n-drop world >>where stateless/asynchronous applications take longer to build than your >>standard "EXE". Time = money, features > platform, reusable OOP > >>include hell. (ok, so the last one's just mine opinion but you know >>includes suck). >> >>Anyhow - I still don't see this mass migration to web apps even if AJAX >>becomes drag-n-drop, not yet. >> >>/David. >> >>David Sommers, Architect \ Dialog Medical >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Jim >>Self >>Sent: Friday, October 14, 2005 11:11 PM >>To: [email protected] >>Subject: Re: [Hardhats-members] CPRS alternatives (was: Cost to convert >>CPRS to Java >> >>Mark Dalton <[EMAIL PROTECTED]> wrote: >>>I was hoping to find a simple solution and to help make development >>quicker >>>and easier >>>for us to work on it and have it truely portable (versus via wine). >> >>I keep hoping to interest VistA programmers in helping with development >>of a web interface >>to VistA starting with M2Web. I believe that comparable functionality >>will require orders >>of magnitude less source code than thick client approaches like delphi >>or java. --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
