comment on VistA Standard Base

[fred trotter]

Hi,
        After having some success with the letter to the VA CTO using co-ment, Ignacio asked me to do the same thing with the VistA Standard Base draft process.

This is a more objective means of moving forward with the a document writing process. For those who care, co-ment is the successor to stet which was the software used for document comment on the GPL version 3. The main benifit of  co-ment is that it is both a FOSS project and an embeddable service from co-ment.net

We have already gone through 7 release candidates on the Hardhats mailing list, and this represents the 9th release candidate.

You can find it here:

http://libertyhsf.org/index.php/vsb

The basic idea behind the VistA Standard Base is to have some assurance that components of Vista are in predictable places. All modern MUMPS-based variants of VA VistA can be maee to conform to the VSB without impacting functionality (that is the idea in any case).

One of the reasons why Unix is so successful is that people generally know that you should look for configuration files in /etc/  and program files in /bin/ or /usr/bin etc etc. VSB is designed to do the same thing for VistA.

While I consider myself a member of this community, it would be sheer hubris for me to presume to call myself a Vista developer. I would like to be however, and things like VSB make VistA easier to for hopefuls like me.

For instance, if I am reading a developer guide and it says:
         "find the patch listing"
I have not idea what that means. I do not know what a VistA patch is, and I have no idea what process I should follow to find that file. However if the instructions read:
         "find the patch listing it lives under /<base_dir>/<branding>vista/<instance>/etc/patch_listing.txt, for openVistA that means /opt/openvista/1/etc/" the first statement is inscrui

It also makes it easier to write meta-tools that work on multiple versions of VistA. Suppose I wanted to write a program that would track patches and automatically record new patches somehow.
I could write a function that would traverse /opt/ for directories containing the term 'vista' and then recurse further to find the patch status for each instance. The alternative is a configuration file that would take an expert to fill out.

With VSB I could write some kind of RPC proxy or firewall system and know that I could count on a particular port being used for VistA, again featuring auto-magical configuration.

I hope I have given a few examples of why VistA standard base is helpful to new developers, and improves the basic modularity of VistA. The decisions made in VSB are somewhat arbitrary but then, the location of /etc/ is arbitrary too, and that seems to work. VSB is valuable precisely because it defines decisions that are by nature arbitrary, so that you do not need to know where everything is, just to get started somewhere.

I have already left some comments on the document. Please help Ignacio to move forward on this.

Regards,
-FT



--
Fred Trotter
http://www.fredtrotter.com