=======================================

Let me apologize for the bandwidth, but my first transmission of this message 
came back to me garbled. I'd like to bother you all and try again.

=======================================


Mark asks:

> I didn't see Wirt's talk, but I did hang around the Adager booth for a 90
>  minute demo.  I am very impressed with QCTerm and its Van Gogh mode.  I
>  couldn't help but think what a fresh face it could put on a lot of older
>  apps.  But then I got to thinking, how would one convert an app like 
MANMAN?
>  The screen model is not conversational, in QCTerm you can jump around but
>  MANMAN loops.  I would think V-Plus apps would be much easier.  For better
>  or worse, the presentation would be closely tied to the business logic.

In the beginning, it may be easier to put almost all of the emphasis in 
writing new applications rather than trying to face-lift old ones. 
Simplicity, reliability, robustness, grace, efficiency, speed and 
attractiveness are all we're trying for initially. Anything beyond that I 
consider to be gravy.

QCTerm has a data flow to it that results in its own unique patterns, but 
those patterns are made to be as simple and as obvious as we possibly can 
make them -- and yet still provide for the capacity to run an application on 
the other side of the world, but allow you to think that it's running on the 
PC next to your desk.

The comment that I considered most telling during the talk was that of Mike 
Berkowitz, who said, "You know you're going to create an awful lot of jobs 
for 12 year-olds." Mike set the bar one year lower than I've been telling 
Vickie, the engineer who's writing QCTerm. What I've been telling Vickie for 
the last several years is that we want to provide a very simple, very robust, 
very efficient mechanism for bright high-school students to write IMAGE 
applications. None of this is supposed to be as complicated as it's become. 
It wasn't complicated when I began. If we're really going to get new 
applications on the HP3000, we have to make it simple again.


>  There have been a few posts on going "back to the future" and I wondered 
how
>  far could you push QCTerm.
>  
>  Will Telnet scale for thousands of users on a system at once?  Would the
>  license model have to change or would one have to buy an unlimited-user
>  license to do large Internet work?  

This is a subject that has been greatly concerning me, too. At the moment, an 
unlimited-user license will be necessary for large-number internet usage, and 
I regret that. Because we're using standard methods of communication with the 
host (telnet, ftp, and http), we've become "platform-" and 
"language-agnostic", meaning that you could write your database applications 
on any host you wished to use (UNIX, Linux, NT, AS/400, etc.). On the great 
majority of these platforms, there is no penalty for an unlimited number of 
telnet sessions. It's only really on the HP3000 that it's a major concern -- 
and yet it was the desire to create a mechanism to foster new applications 
development on the HP3000 that has driven the development of QCTerm.

The idea of QCTerm came to me six years ago during a SIGIMAGE executive 
committee meeting at Cupertino with Harry Sterling, Jim Sartain, Jon Bale, 
Kris Rant and a few others. Steve Cooper made a point then of mentioning that 
unless the HP3000 gets a new face, it's going to have a rough time -- and 
there won't be any new application development. I thought about Steve's 
comments for about a year before we committed to beginning to build QCTerm, 
essentially evaluating every possible architecture (browser-based, 
Java-based, application-specific, etc.) as far as their simplicity, 
reliability, usability, etc. for high-speed data entry. The current design of 
QCTerm is the result of thought process. 

While it's taken much longer to get to this point than I initially imagined, 
and we're still about a year away from completion, it's also working out 
nicer than I might have originally predicted. In fact, I'm as impressed as 
anyone. I sit here and run my application simulations off of Neil Harvey's 
967 in South Africa day after day, deducing what works well and what doesn't, 
and get a little more impressed each day myself. But no matter what we do, it 
has to be extremely simple ("Simplicité. Toujours simplicité"), extremely 
reliable, and extremely responsive. In the end, it has to be usable and 
useful -- and RELIABLE -- to ordinary people working in an standard office 
environment, anywhere on the planet.

We're not trying to emulate a web browser's behavior in QCTerm. In fact, 
we're trying very hard NOT to duplicate the basic functionality of a web 
browser, although there will inevitably be some small overlap. What we're 
trying to do instead is to provide a mechanism that will create the 
front-ends that are common to the very best PC-based applications. These 
applications don't look like web-browsers. They have their very own look and 
feel -- and they're generally more comfortable and easy to use than web-based 
forms. But there's no reason we can't do the same for the HP3000; it's just 
that the application's logic and processor will no longer be on the PC, but 
rather on an HP3000 three thousand miles away.


>  Can you get around the firewall issue
>  with Telnet?  

Yes, but not if someone blocks telnet access.



>  Would QCTerm eliminate the need for web pages or do you still
>  need them?  Does QCTerm become the standard for doing maintenance and web
>  pages for read only interactions?  

QCTerm is not being designed to be competitive with web pages. HTML works 
very well for what it was designed to do; it was just never designed to be an 
OLTP process handler.

Web pages are now and will be for the foreseeable future the de facto 
standard for simple access to the web. QCTerm sessions will be web-launchable 
as a helper application/player, in the manner than Real Player, Windows 
Media, Quicktime, and Adobe Acrobat "players" are now. However, QCTerm 
sessions can also be logged on by hand, as you would any terminal session, or 
logged on through a user's menu, or logged on from a PC-local script file 
stored in an icon.



>  Could you get enough folks to download it
>  or would you want the "QCTerm Markup Language", QCML (a FLA BTW),
>  implemented in browsers and other terminal emulators.  

While I don't know if I fully understand the comment, if "QCML" were launched 
as a web browser process, we'd be right back where we started (the "old" way 
of doing things, without state, fragile and complex).



>  Will QCTerm be
>  available for Linux and/or Mac?  

Let me rephrase the question: Will QCTerm be available as native code for 
Linux and/or Mac? I doubt it. While there's always an outspoken lobby for 
these subjects, in pure practical terms, QCTerm has cost approximately 
$500,000 to date (and continues to accrue about $10,000 to $15,000 worth of 
charges per month)  -- and that's for a product we intend on giving away for 
free forever. 

But the more important reason is that if you look at a pie chart of the 
market penetration of each of the platforms in a business environment, all of 
the various versions of Windows account for greater than 97% of the market. 
Macs account for about 3%. And all other desktop platforms, including Linux, 
are less than a 0.1%.

The ratios are probably even more skewed in the HP3000 community. There's 
just no business case for writing for these other platforms, especially in 
corporate environments where platform consistencies are mandated (and no one 
to my knowledge nowadays is mandating Macs or Linux).

But if QCTerm does ever run on Macs and Linux, it will be because these 
platforms have come to us, not us to them. That's not an idle statement. The 
pressure is on these platforms to become Windows-compatible, and the pressure 
is really quite strong. For all of the diversion that web pages have 
temporarily provided, the presence of applications still very much matter. 
Linux has the WINE (WINdows Emulator) initiative, which more or less lops 
along at some pace. Eventually, it's likely to become a reality (see, e.g., 
http://www.linuxgames.com/wine/ )

And the newest Mac OS (named "X") is a purposeful double-entendre. Apple 
wants you to pronounce the "X" as "ten", but the "X" also stands for 
UNIX/POSIX. OS X is basically UNIX on the Mac, with its "legacy" (native Mac) 
code running as a domained subprocess. Apple has declared OS X to be an 
"open" OS, and I strongly suspect that if WINE succeeds on Linux, it will be 
almost immediately available on the Mac.


>  Would it be useful if QCTerm could display
>  multiple resources on the same screen - not graphics and such, but multiple
>  connections?  (For example, connect to the MFG server and the Order Entry
>  computer and display info about a part's orders and supply)  

Simplicity remains the absolute watchword in this design philosophy. The 
model underlying QCTerm is a "Beauty & the Beast" architecture, where all of 
the intelligence is placed on the host and QCTerm acts only as a very simple, 
very pretty, but very dumb thin client. ("Beauty & the Beast" is just another 
way of saying "host-terminal").

If you want communication between two host processors, that communication 
should be done between the machines directly, beyond anything that QCTerm 
would know about, and let one of the two hosts write its data and the data it 
extracts from the other machine onto QCTerm's screen, as if it all came from 
just one machine.

Finally, let me say how pleased I was this year by how many people caught on 
so quickly to the profound possibilities that all of this represents. Last 
year's talk didn't generate that reaction, in great part because I think it 
came as a bit of a shock that a terminal could generate graphics at all, and 
that was a distraction, and in great part because I could only describe where 
we were going and not actually show anyone yet. Next year's talk should be 
even be better. I've already decided on the title of next year's talk, which 
will be something like this:

     "Creating new applications on the HP3000 de novo, quickly, easily and 
with great efficiency using QCTerm."

As I say, none of this was complicated when I began programming on the HP3000 
25 years ago. Between IMAGE's intrinsic simplicity, reliability and 
robustness and our very strong desire to impose these same qualities into 
QCTerm, I think we can make this all simple again.

The great trick will be for the next several years will be resisting all of 
the tugs and pulls to make all of this more complex again.
 
Wirt Atmar