You mentioned the Broker documentation, and I know you are not referring to this particular documentation, but I was poking around the Broker components while attempting to use Delphi a few months back and the Help files with them were really wonderful. It was like a friend was right there trying to help me out and was doing a bang up job of it.
On Friday 21 October 2005 04:31 pm, 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. 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. 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 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. 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. 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... > 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/D >atabase/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 ------------------------------------------------------- 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 -- Nancy Anthracite ------------------------------------------------------- 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
