Richard Schilling wrote: >> Very interesting. On the surface this sounds similar to some of Steve Zeck's >> initial work >> in making a Perl interface to GT.M. In the first level he defined a Perl >> module for >> implementing MUMPS data objects. These data objects represent MUMPS globals >> and have >> methods corresponding to all of the standard functions for working with >> MUMPS data. In the >> second level he has begun defining higher level objects that correspond to >> the data >> records from the fileman defined data structures. > >I haven't seen Zeck's work.
The basic MUMPS interface is a Perl Module called Db-GTM available from CPAN. http://search.cpan.org/~szeck/Db-GTM-1.27/GTM.pm It's worth a look if you are at all interested in accessing MUMPS data from other programming languages. I would like feedback from anyone who gives it a serious look or actually uses it. It is designed to be natural and easy for Perl programmers to work with without sacrificing any of the speed or functionality that MUMPS programmers take for granted. >But, one thing I decided early on was to >start with a very simple interface - from the bottom. We've already got >the top-down design elements (object models, table models, VistA data >models, etc...) handled, really. Do you actually have a representation of the VistA metadata in your code already? I didn't see this or perhaps I didn't recognize it when I saw it. Admittedly, I took a very quick look at the code, but that was exactly the sort of thing I was most interested in finding. >What I've focused on was a very simple >bottom-up approach: send a string to the server over a socket and get a >response back. > > >> >> I think there is quite a bit of common work to be done in analyzing the >> functionality and >> devising a high level interface to it regardless of your approach and >> technology. For >> instance, a listing of what data elements are involved in different reports, >> interfaces, >> and data entry forms, how those relate to functional areas and menus, and >> how they map to >> data elements from other systems. > >Correct - OpenEMed's design takes this approach with respect to >interfaces. This is what CORBA and the CORBAMED standards give us. The That would be great if true, but I suspect we are not talking about the same things. I was thinking of the functionality and data in VistA. I already have metadata driven web interfaces in M2Web that expose the data and metadata in JSON, HTML, and XML formats. Perhaps these could be used as a starting point for a higher level interface to CORBA? >other tasks - identifying discrete data elements/reports/etc... has >received a lot of attention. There's more documentation on that then >anyone has time to read. ??? Please point me to where this essential part of the design of practical applications in VistA is clearly layed out. > >Also, some of the challenges anyone faces in laying an object model on >top of a mumps data store are: > >* handling the fact that the MUMPS data store is a b-tree structure: >with all the "SQLesque" table design structures out there - including >those in VistA (e.g. fileman) - there's some extra work in mapping >things properly. What do you mean by a "proper" mapping? >The irony is that the Greystone data store b-tree is a >natural fit for object-oriented data models, but storing data like that >wasn't a design goal of the original VistA developers. Fileman was >created, rather, to give developers and users kind of a "file systems >view" of VistA. It's easier to export VistA data into flat files right >now than to build up a proper object heirarchy as a result. ESI Objects >addresses this nicely, but I'm not at the point yet where I can spend >the time to take advantage of it. > >* limitations mumps places on data storage: mumps references need to be >created properly, and mumps commands have a limit of 255 characters, etc... No they don't. Most current MUMPS implementations can store thousands of characters in a single data value and can execute command lines of thousands of characters also. Data stored in GT.M globals is limited by the block size (4KB, 8KB, 16KB, etc) of the datasets used for individual globals. There is a configurable limit (default=2KB) on the size of executable strings, but string length for local variables is currently 1MB. >> Documentation and discussion of the difficulties and complications and other >> substantial >> findings could be helpful to others considering reverse engineering or >> re-engineering with >> other languages or approaches. >> > >I don't get the impression that there's an interest by the RPC Broker >creators to have it reverse engineered. it's pretty obvious at the lack >of documentation, isn't it? > >It's a valid design choice on their part - just use the Delphi >components. In my case my customers haven't requested that I use >Windows based Delphi components, and it's not an option to build a Java >applicaiton around them anyway. > >ESI objects is a valid choice in lieu of Delphi components - if you have >the time to work with that product. >>>src/tools/gov/lanl/Database/GTM for OEMEDSRV.m). >> >> >> I looked at it a little. I think I found some minor errors where you are >> converting search >> filter operators to MUMPS in function convertOperator >> http://cvs.sourceforge.net/viewcvs.py/openmed/OpenEMed/src/tools/gov/lanl/Database/GTMSearchFilter.java?rev=1.4&view=auto >> >> ">=" (greater_than_or_equal_to) is not a standard MUMPS operator (at least >> in GT.M 4.4). >> The equivalent is "'<" (not_less_than) >> >> "<=" (less_than_or_equal_to) is not MUMPS. The equivalent is "'>" >> (not_greater_than) >> >> An equivalent for "in" might be "[" (contains), except with the operand >> order reversed. >> >> How far have you gotten in generating MUMPS search conditions? > >This is a very early release of the code - perhaps too early. I'm >working through the issues you mention issues and many others you'll find. > >One challenge here is that OpenEMed is designed to work well with SQL >like language structures such as the "LIKE" command. I have some more >work to do to get my code to function under the OpenEMed design model as >it should. >Richard Schilling >Cognition Group, Inc. >Seattle, WA --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
