On 01/24/2012 07:30 PM, Karsten Hilbert wrote:
On Tue, Jan 24, 2012 at 06:49:03PM -0500, Bhaskar, K.S wrote:
[KSB] <...snip...>
So, from a size point of view, VistA on the server side will be about the size of a pure-server GNU/Linux distribution. No problem. Want to run a hospital ? Better have the beef.
[KSB] Some of us vegetarians would prefer to hold the beef and have tofu instead! :-)
But jokes aside, let's stay with the comparison of a VistA environment being like a Linux server because the analogy is good.
The complexity of VistA comes from its vertical integration. Consider an office suite or a web server. The package is quite separate from the content. It's easy to upgrade LibreOffice without touching the documents, spreadsheets and presentations created with it, or to upgrade Apache without touching the web pages that it serves. VistA is not like that.Many applications (really) using databases are like that, consider OpenERP, or even GNUmed - you cannot just upgrade GNUmed (major versions, that is) and NOT upgrade the server and database part and still access the patient data. Any given client (major) version requires a certain database schema version (of course, GNUmed provides scripts to go from one version to the next). And it's not just the database layout but rather also in-database functions that will have changed. Naturally, VistA is way more sophisticated in that regard but the basic concept seems to be the same. If not, further explanation will shed more light on what's needed.So, what a VistA Debian package can do is provide the core VistA system that can be installed on a computer and from which environments can be created on that computer. Existing environments cannot be upgraded by installing an updated Debian package. VistA has its own package management system (called KIDS) and each installed VistA environment on that computer will need to be upgraded by applying KIDS packages.It is helpful to know the above. Nevertheless, an "updated Debian package" might be a collection of KIDS packages conveniently bundled together to KIDS-basedly locally upgrade an existing VistA, no ? Or else it might be a script *initiating* a KIDS-based upgrade based on a list of "pre-selected" KIDS packages (rather than *containing* them KIDS) ? PostgreSQL / Perl / R / Python / LaTeX / Ruby (?) all have their own package/extension management. Both selected Debian-packaged extensions as well as packages installed from each repo can co-exist. A KIDS upgrader tweaked to play nice with a Debian system might exist and be called in postinst from apt-get upgrade when there's a new VistA-server available. It's probably much more complicated than I think but essentially it's mostly about glue. Lots of it :-)
[KSB] Let's work with the analogy between VistA and Linux.A VistA Debian package is like a Linux installer ISO image. It's a tool that will let you create new VistA environments on your computer, just like the Linux installer ISO image allows you to create new Linux virtual machines to run on your computer. Each newly created VistA environment is the same just as every newly created Linux virtual machine is the same (let's overlook file system UUIDs for now).
Once you start using and customizing each Linux virtual machine, it starts diverging from others that you created from the same installer. It's the same with VistA environments.
You can update each virtual machine with aptitude and Debian package updates. You can update each VistA environment with KIDS packages. There are rules for configuring your Linux virtual machines so that package updates go in smoothly. But depending on the type of customization that you need to do, you may end up with configurations where most packages go in smoothly but every now and then, you have a package with a conflict that you need to resolve manually, or where a package overrides your configuration which you then need to restore after running aptitude. So, you must run aptitude on each virtual machine individually: you can't run aptitude on your host and update all your virtual machines in one fell swoop. Similarly although there are rules for configuring VistA so that KIDS packages go in smoothly, in practice there are usually some configuration settings that cause issues with some KIDS packages, so you can't just drop packages in - you have to test before applying each package and you have to make plans to deal with each conflict. Also, just as, if you are a Linux developer, you can use your Linux virtual machines to develop new packages that you can export to other Linux systems, from a VistA environment you can create KIDS packages to export for other VistA environments to load.
In Linux, when someone creates an updated Linux installer you can't just use it to update your existing Linux environments. Although it is theoretically possible to reverse engineer the packages from the new installer and apply them to your existing environments, it's probably easier just to update the existing environments by applying the package updates.
I hope this helps. If not, please keep asking questions and I will do what I can to answer them. I am not a VistA expert, but I have absorbed enough through osmosis that I can give reasonably good approximate answers, and know where to go to get exact answers when needed.
Regards -- Bhaskar
Karsten
-- 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.