The Hardhats are going to have a good old-fashioned barn raising! We plan to develop a software application that can be given to the Department of Veterans Affairs to make it painless for them to post software patches in archives for folks both inside and outside the VA. A win-win for everyone.
(contact Greg Kreis to volunteer.)
|Required Skill Sets:
The following collection of notes will guide the Patch Barn designers in their prepartions for the raising.
Software Design ideas:
Here are some objectives for an automated patching system. For more information about the requirements, you may want to contact the VA's DBA (Cameron Schlehuber).
|Specifications of the message formats:|
According to Cameron Schlehuber, here's the patch and HFS structure in a nutshell:
patch message structure:
$TXT creation title etc. } These lines are optional but
... } if present must be bracketed
$END TXT } with $TXT $END TXT
$KID nmsp*vn*pn } E.g., PSJ*4.5*42
**INSTALL NAME** } Always the same
nmsp*vn*pn } E.g., PSJ*4.5*42
... } part of the load global root
... } and its data
$END KID nmsp*vn*pn
HFS file structure:
creation title etc. } free text
comment line } may be blank, but must exist
**KIDS**:nmsp*vn*pn^ } note colon and circumflex!
} blank line
**INSTALL NAME** } This is the
nmsp*vn*pn } same as
... } the text in
... } the patch.
**END** } Always the same
**END** } Always the same (yup, twice!)
} linefeed after 2nd **END**
The name of the HFS file should closely match the patch name structure, but needs to be compatible with NT and UNIX standards. I suggest nmsp-vn_dp-pn.kid ... where vn is the whole number part of the version number and dp is the decimal part, and instead of "*", "-" would be used.
To be convenient to use, one should be able to have an option to select one or more message numbers, as well as those in a range, and be able to enter the destination path. Note that sometimes patches have no code (i.e., $KID etc., doesn't exist). These should default to not creating any file entry and skip gracefully. Perhaps even more convenient would be to have a Server that could "receive" all such messages, with a parameter entry to define the default destination path, and automatically process all such received messages.
Search | Home | MUMPS | Fileman | Kernel | C/S, Mailman, Web | Programmer Tools | Applications