Thirteen people responded to the questions I asked yesterday regarding blobs
and the van Gogh mode of QCTerm. I greatly appreciate the comments.

As to the comments regarding the question of whether you would prefer to have
responsivity vs. automagic blob substitution, the votes were:

     9 were for high responsivity
     0 were for automagic file substitution, although one
        comment could be read as leaning for the process
     4 (or 3) offered no opinion

As to the question of FTP vs. HTTP:

     9 said they either supported the switch to HTTP or
        that they had no requirement to use FTP
     2 said that both protocols should be supported
     2 offered no opinion

The two people who argued that both protocols should be supported were the
two that answered publicly: Steve Cooper and Ken Sletten. Steve suggested
both are necessary because of "firewall gods". I know that this is a problem.
Virtually no one at HP has seen the van Gogh mode of QCTerm because neither
Telnet nor FTP is allowed through the corporate firewall. (In fact, to see
the demos that a lot of you have seen running off of our 918DX, the HP-er's
that have seen them have had to get up and drive over to Allegro to watch
them :-).

Steve's comments underlies another one of the reasons my desire to switch
over to HTTP. Virtually everyone lets the HTTP protocol go through their
firewalls. Without it, no one on the inside can view web pages. But that
alone wouldn't fix the HP-to-AICS problem. Telnet (which is by far the more
important channel) is still blocked.

Ken, while readily accepting the idea of using a "foreign" blob server,
running on NT or Linux somewhere else, would like to have see FTP supported
so that his applications and his blobs could be served off of the same
HP3000. Implicit in Ken's comments is the fact that FTP is, at the moment, a
great deal more common on HP3000's than is a webserver.

But that's at the moment. Anonymous FTP didn't come to the HP3000 until 6.0,
and it is my understanding that Apache is now part of the FOS with 6.5
(although we haven't gotten our copy yet). Non-anonymous FTP -- as much as I
like it -- simply can't be used in a open-to-the-world production
environment, thus your machine has to be on at least 6.0 to use it. As time
proceeds, I'm sure that the Apache webserver will become an increasingly
integrated part of the FOS and as easy to turn on and configure as FTP has
become.

Nonetheless, Ken's and Steve's comments, even though they were in the decided
minority, have carried the day. We will support both protocols (and any other
reasonable protocols that might pop up later). However, we couldn't have done
it if most people had voted for "automagical" out-of-date blob file
substitution. As I said earlier, we can find no (even reasonably) consistent
way to determine the last-modify date of files on that are resident on
NT/Linux/UNIX/3000 servers, thus automatic re-downloads were looking quite
difficult to program up, requiring the construction of essentially
host-specific (and thus, on the long-term, very fragile) code.

But no one voted for the process, either. And that's my vote too. The most
common comment was that the blobs were very likely going to be very static
for the applications they had in mind.

There are several significant advantages to not negotiating the currency of
each blob in cache. One is certainly the dramatic increase in speed. If you
have the necessary files in cache, you're ready to go. But a second
pronounced advantage is reliability. On Easter Sunday, when I was playing
with the HTTP code, running the blobs off of our ISP's Linux box, they took
their machine down for the afternoon to perform an upgrade -- and I couldn't
extract blobs or continue to write code for those several hours.

If you're running two boxes, with two completely independent paths, you've at
least doubled your overall system unreliability. If the necessary blobs are
completely cached, resident on your PC, and we don't ask for date
confirmations, then you'll never notice the blob server has gone off-line.
The application host (the HP3000) is the only machine of importance in that
circumstance.

Ken argued for FTP for a very similar reason. He would like to serve the
blobs from the HP3000, thus making overall systems management much easier,
along with having consistent backups. I very much agree with those goals
(with the only caveat being that HTTP will undoubtedly become as commonly an
implemented protocol on HP3000's as FTP in the next few years and thus this
desire isn't critically dependent on supporting FTP).

Based on these comments, this is the way we'll go. No date negotiation and
support of both FTP and HTTP. As I say, I very much appreciate the comments.
If you disagree with anything I've said here, please don't hesitate to let me
know.

Wirt Atmar