As a long time MUMPS programmer, I too have always thought that a binding of
something like Fileman to CORBA would be more appropriate than simply a
binding to MUMPS. I imagine that I probably do not have a correct
understanding of what exactly a MUMPS to CORBA binding would entail.
Perhaps the misunderstanding on this issue, if there is one, is due to the
extreme simplicity of the MUMPS data abstraction. Mike Simpson touched on
this a few messages ago referring to his early confusion when coming to
learn MUMPS from a background in C derived languages.
In MUMPS, data values behave like strings while variables behave like
hierarchical file systems, some of which (globals) are persistent and shared
and capable of efficiently scaling to handle extremely large numbers of
entries at each level of the hierarchy. Unlike file systems I am aware of,
MUMPS variable hierarchies are intrinsically ordered.
Another source of confusion is the use of the term "file" in "Fileman" to
refer to what is now more commonly called a "relation" or "table". Fileman's
use of the term "file" originated when MUMPS systems were self-contained;
before they were layered on a general OS and "file system" and before
relational database terminology became widespread.
Gregory Woodhouse wrote:
>Okay, I see what you mean. Perhaps what I wasn't clear about is that we
>would not want to go directly to the globals. (A global is a MUMPS
>abstraction representing persistent storage. Basically, it is a tree in
>which each node has a name and all sibling nodes must have distinct names.
>In addition, any node, leaf or not, may have data associated with it.)
>Global storage is the mechanism used in Fileman to actually store data, but
>Fileman provides a logical data model which is quite distinct from the one
>I just described: Fileman supports logical files,
-- noted above as another source of confusion -
>data types, multiple valued
>fields (or, if you prefer, user defined types/domains), integrity
>constraints, security, pointers and variable pointers. It's this logical
>model that you want to use when creating an interface rather than the
>physical (global) storage). My second point was that I thought the DBS API
>is well-suited to creating a binding to an object framework -- perhaps not
>surprisingly since the DBS API is actually quite young, being released as a
>patch to Fileman v. 21, and it was originally intended to provide database
>services to Delphi components. In fact, there is a set of controls known as
>the Fileman components that is part of the official release. True, Delphi
>components are not CORBA, but they *are* objects. DBS was designed with
>encapsulation in mind.
>
>===
>Gregory Woodhouse <[EMAIL PROTECTED]>
>Financial Product Line
>+1 415 744 6362
>"Computer science is no more about computers than astronomy is
>about telescopes." -- E.W. Dijkstra
>
>
>-----Original Message-----
>From: David Forslund [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, January 20, 2000 7:31 AM
>To: Gregory Woodhouse
>Cc: [EMAIL PROTECTED]
>Subject: Re: "thrill of development" - MUMPS
>
>
>Sorry I misunderstood. It would seem that to use the DBS API in a CORBA
>framework, one still needs a CORBA/Mumps/M binding.
>
---------------------------------------
Jim Self
Manager and Chief Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
