(In writing this post, I am building on my recent reply (same date in my
timezone) to a post from Karsten Hilbert with the same Subject.)
KIDS is used to patch a VistA environment. A KIDS build contains updates
to both routines and the database. Since each VistA environment is
self-aware (just like a Debian GNU/Linux system), the KIDS build contains
information about itself, and you can query a VistA system about its
patch history. So, a KIDS patch is applied to a complete, functional
VistA environment.
In the example from the other post, where Karsten has a VistA environment
(E,C,B,A) and Bhaskar has a VistA environment (F,C,B,A), and both have
their own databases, a patch would be applied separately to E and F. In
case Karsten and Bhaskar have decided to share the database, the patch
could be applied to C - but after checking to ensure that it doesn't
update routines in E or F (and if it does, Karsten and/or Bhaskar will
need to manually reconcile and merge changes from the patch to their
versions of routines in E and F).
An analogy between VistA environments and GNU/Linux installations comes
to mind. Imagine two GNU/Linux virtual machines running on a GNU /Linux
host. The root file system of each vm is actually a union of the root
filesystem of the host overlaid by a file system of the guest. You can
manage packages on each guest and those changes affect only that guest -
they don't affect the other guest or the host. The safe way to manage
packages on the host would be to apply the package changes to each guest
and then apply the same set to the host. You can potentially destablize
the virtual machines by removing a package on the host on which packages
in the guest depend.
Regards
-- Bhaskar
On 07/11/2012 02:46 AM, Andreas Tille wrote:
Hi Bhaskar,
thanks for your explicite explanation. I keep on trying to understand
the big picture. Could you please try to inject the role of KIDS into
the context below?
Many thanks for your help
Andreas.
On Tue, Jul 10, 2012 at 10:33:02PM -0400, Bhaskar, K.S wrote:
When an office suite is installed on a computer, one expects to type
something like "soffice" and run it because (a) you only need one
instance of it on the computer, (b) it does not need further
configuration to run, and (c) you don't have complex shared editing
where for example two people may be editing a shared word processing
document, with an embedded spreadsheet that one person has
read-write access to and the other has read-only access to, etc.
VistA is more like a database such as PostgreSQL, where after
installing the Debian packages, you must still create and configure
separate databases. But unlike PostgreSQL, VistA environments may
be chained and you can have trees of environments. So, VistA is a
little more complex than PostgreSQL.
(You can look at the VistA "SemiVivA" packages that I have packaged
and released over the last several years to see how what I describe
here works in practice - it's all done with a few shell scripts, all
under a page.)
When VistA is installed on a computer, one normally needs multiple
instances. So, a single institution may have a production
environment, a pre-production (staging environment), multiple
development environments, etc. Or, one may want to run multiple
production environments, for Clinic A, Clinic B, etc. Each
environment may have its own users and groups to manage access
(there is no need for a system wide "vista" user or group). After
installing vista with apt-get / aptitude, one does not expect to
type "vista" and run VistA. Instead, one expects to type a command
such as "install <directory>" to install a working VistA environment
in <directory>. When creating an environment with a command such as
"install <directory>", each environment usually gets its own
database shared by all the users of that environment. For routines,
each environment gets a search path that finds its (small number of)
private routines first, and then the (large number of) shared
routines. Environments can be chained. In such an environment, you
can type "vista" and run VistA.
Each VistA environment needs configuration before it can do anything
useful. Before you can record a patient visit, you have to create a
provider to see the patient, a location, and a patient. So, after
creating an environment, you would type "vista" to get a tabula rasa
to start configuring.
VistA environments have controlled access. Thus, the VistA
installed by the Debian package would be world readable, but not
writable by anyone. Each environment might have multiple users who
are all members of a group. The database would be read-write by the
group.
Regards
-- Bhaskar
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
o
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
