Some comments on the original design of MailMan's server and patient addressability capability

At today's architecture call, folks talked about the Extended Action Protocols of VistA.  This reminded me of some of my original design goals for MailMan, which I thought I'd comment on here.  I don't know how this all relates to today's VistA platform, but here are my thoughts from days of yore...

I designed MailMan to be a general messaging and communication system, with the name unfortunately giving the impression that it was just an email handler.  I added a syntax to the recipient parser, so that S.<servername>@<domainname> would route a message to server <servername> at VistA site <domainname>.  P.<patientname> would route a message to a patient, G.<groupname> would send a message to all recipients in <groupname>, etc.

The protocols discussed today seemed to fit into the S.<servername> syntax.

We didn't have JSON or XML back then, so we had to invent a serialization technique, called FileGrams.

I developed this as part of the March AFB/Loma Linda interface effort in the early 1980's.  For example, we might have sent a message from Admissions@Loma-Linda.va.gov to s.Admissions@March.af.mil

P.<patientname> syntax was a way of communicating with patients.  I never implemented it, but I was thinking of having a patient preferences section that would name how best to communicate with them.  This could be a letter through the USPS mail system, a telegram, a phone call, or gasp! an electronic message to the patient if things ever advanced to that stage.  (I was thinking of the VA offering email service to veterans at the time).  Notice how this approach would allow the system to adapt to changing times.  If we wanted to change the delivery model to SMS text messages, Facebook, or Twitter, this would have been a very simple plug in adapter.

This is a wildly different design aesthetic than designing everything as an API... it is tying the system through language, in the same way that HTML, HTTP, and URIs tie together the web.  The web is not a collection of APIs, but rather a space bound together by language references.

Better yet, Google does away with the binding altogether and just lets folks type in free text.  Google users don't have to say "I'm looking for a person named SMITH" - you just type in "Smith" and Google does its thing with it.

I have to admit that looking at today's designs, I'm suffering from API-shock.  It seems like there are an exploding numbers of APIs, and the more, the merrier.  I don't think I ever designed and API in my entire VA tenure.  I built language interfaces (like S.servername) and buried the interface as an indirection. (a symbol representing another symbol, which then represents the value.  (or another symbol).

This general approach is comfortable to the LISP/Smalltalk/MUMPS world that didn't make the same concrete distinctions between data and program that Cobol, C++, and Java did.

Another factor was that MailMan was targeting to build a user community... the FORUM instance of MailMan eventually grew to 50,000 users. It was a kind of "community engine" - akin to the way that Wikimedia wiki is a technology engine to Wikipedia.  It's a little like trying to point something out to a dog, and it looks at your finger instead of where you are pointing... geeks tend to get stuck looking a the internals of the technology (e.g. the PHP code in Wikimedia), rather than the community of users it supports.

 

 

like0