Gregory Woodhouse wrote: >Oh, I quite agree that this would be a worth project. In fact, I have >been exploring a Java/MySQL implementation, but unfortunately, it has >been temporarily sidetracked by my ever growing "to do" list. > >I do not mean to sound like a broken record here, but I am much less >sanguine about the possibilities of an interoperable MUMPS >implementation precisely because of the not insignificant problems with >the I/O model (and support level) that I mentioned yesterday.
Hmmm. I wonder if the problem you perceive is in the conception of a MUMPS-only server. For instance, the device handling in most MUMPS implementations is not suited to the direct implementation of an HTTP server. The inability to hand off a web request from a general listener to an application handler without leaving non-listening gaps means that a server will begin to fail intermittently by losing requests at a very low number of requests per second. With the help of a general web server, such as Apache used with M2Web, device handling virtually disappears from most web applications and performance and capabilities go way up. >Unicode >support is a must, Although more direct support for 16-bit or 32-bit character encodings would make some things simpler, working with UTF-8 in MUMPS, or specifically in GT.M, does not seem like a big deal to me. As mentioned in previous messages, it seems to be pretty well designed to be handled easily with tools available for 8-bit characters. >proper socket support is a must, and yes, I think >non-blocking I/O is a must, too. Ability to pass streams to "consumer" >processes is a must (the current model of copying messages into globals >be for further processing can occur is simply not enough). There are lots of ways to improve performance by relying as needed on features in the operating system outside of MUMPS. What sort of data volumes are you thinking of? How big are these messages? > >==== >Gregory Woodhouse >[EMAIL PROTECTED] >On Apr 30, 2005, at 11:33 AM, list repository wrote: > >> >> Web services allow different applications from different sources to >> communicate with each >> other without time-consuming custom coding, and because all >> communication is in XML, Web >> services are not tied to any one operating system or programming >> language. For example, >> Java can talk with Perl, Windows applications can talk with UNIX >> applications. Web services >> do not require the use of browsers or HTML. >> >> It would be great if VistA supported CCR (Continuity of Care Record) >> in some shape or form through Web Services... --------------------------------------- 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: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
