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.
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. -----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
