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 describedl: Fileman supports logical files, 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.
