Adding my two bits' worth, for what they're worth.|
First, the easy part. The mechanics of creating a Debian package of VistA will be completely straightforward. I know because I have created many VistA installers.
VistA will be distributed as a large number of source program files and database extracts, 100% ASCII source code. The Debian package will be around 175MB (33MB routines zipped, 141MB database extract zipped, less that 1MB miscellaneous zipped, such as shell scripts). Routines will be compiled on the local machine by the postinstall script. In fact, compiling routines can even be optional because GT.M compiles them on demand.
A binary Debian package doesn't make sense: the object files will be approximately twice the size of the routines and both routines and object files will be need to be in the package anyway - one of the features of the M language is a $TEXT() function that allows a program to look at its source code at run time, and most M applications use $TEXT().
VistA consists of over 25000 routines of M source code. For example, with the WorkdVistA EHR flavor:
gtmuser@gtmworkshop:~$ ls -l /opt/WorldVistAEHR/VOE10/r|wc
25164 201306 1559911
gtmuser@gtmworkshop:~$ du -sh /opt/WorldVistAEHR/VOE10/r
M source code, especially as written for VistA is information dense. Here is a completely random sample:
IEN . ; otherwise, we're in the IEN subscripts & need to process
. I DIVAL="" S DIDONE=1 Q
. I DINDEX="B" N DISKIPMN,DIMNEM S DISKIPMN=0 D Q:DISKIPMN
. . I $D(@DINDEX(DISUB,"ROOT")@(DIVAL))#2 Q:'^(DIVAL)
. . E Q:'$O(@DINDEX(DISUB,"ROOT")@(DIVAL,""))
. . I DIFLAGS["M" S DISKIPMN=1 Q
. . S DIMNEM="" Q
. I $G(DINDEX(DISUB,"TO")) D Q:DIDONE
. . Q:$D(DINDEX(DISUB,"IXROOT"))
. . D BACKPAST^DICLIX1(DIFLAGS,.DINDEX,DISUB,DIVAL,.DIDONE) Q
. D TRY
There are a couple of (proprietary) M to Java converters, and the story has it that when someone tried running one on the VistA code base, they ended up with around 5GB of Java source code.
So, from a size point of view, VistA on the server side will be about the size of a pure-server GNU/Linux distribution. It is a character mode application. Client applications are completely separate.
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.
In VistA, the code and database are tightly integrated. Even sites that use only part of the functionality of VistA invariably install all of it, because even if you only want to implement minimal functionality (e.g., Admission/Discharge/Transfer), it's almost impossible to pull that apart from everything else. Once you start configuring a VistA environment (e.g., by defining locations), it becomes more integrated. Once you add patients, that's another layer of integration.
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.
I hope this is good beginning.
On 01/24/2012 12:37 PM, Luis Ibanez wrote:
This is email is the continuation of a conversation
-- 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.