by Charles Brabham N5PVL
This article was featured in the June 97 issue of QST, in Digital Dimensions.
It's fairly certain that HTML will figure in packet radio's future. The documents
themselves are just ASCII text, which AX25 packet handles just fine. It's unlikely
though, that hams accustomed to using Internet HTML with it's rich graphics will
be content with just text. Hams will want to have graphics in the packet "hampages"
which HTML for packet will introduce, and on servers such as BBS programs and DX
clusters.
Who knows? It may come to pass that such common packets as node I.D.'s and BBS
"mail-for" beacons may be sent in HTML format someday. We'll want to see graphics
on all of that, too.
This article is about how we can do this on an everyday basis, without further
overloading our network with a constant stream of graphic files.
There are two problems with graphics files and packet radio; The graphics files
are binary information, and they are big. These two factors place severe limitations
on us when we attempt to transmit this kind of info over a packet radio network.
Binary and Big translates effectively over to Unreliable and Slow. There are
ways to get around these difficulties, but the fixes introduce delays and
additional complications of their own.
In the end, there's no getting around the fact that transmitting graphic files
over a shared RF net is something to avoid whenever possible. We will eventually
speed things up, but will (hopefully) also have a lot more users by then. This
isn't a limitation which is likely to "go away" in the near future, and it's best
that we plan accordingly.
The standard cache setup for HTML browsers will not handle the needs of packet radio
by itself, since it requires an awful lot of graphic files to be transmitted in the
most common of situations.
For example: A ham connects to an HTML BBS over a poor, long, or very busy link.
It's his first connect of course, so ALL of the graphics for the BBS's "page" would
be transmitted to him since his cache doesn't have ANY of the BBS's stuff. --
That's a lot af graphics being transmitted, in a very common situation! You can
figure on this, and things like this to happen all the time on AX25 packet with
standard HTML cache-ing. It's a terrible waste of everyone's time and spectrum,
and needs a bit of help in order to fit the needs of the packet radio community.
As I understand the use of the HTTP/HTML cache, the transmission of graphics
would occur when Ham-1 first connects to Ham-2. They go in Ham-1's cache directory,
and thereafter won't need to be transmitted (by Ham-2 to Ham-1) again unless:
1. Ham-2's graphic file has changed.
2. Ham-1 loses his cache for some reason, such a HD crash, new software, Murphy,
ect..
3. Ham-1's cache is limited in size, and the graphic was overwritten by more recently
seen stuff. ( fairly common )
This works out great on the Internet, where you have a high-speed, dedicated link
to work with.
In the rather busy, chaotic conditions often found on AX25 packet though, it would
not be satisfactory at all. With packet radio, you have to contend with LOTS of
new guys, lots of guys with software/hardware problems, lots of hidden transmitters,
and (most importantly) LOTS of users sharing the frequency. Under those circumstances,
any transmission of graphic or binary files should be avoided if possible,
especially in relation to activities or functions which occur frequently.
There should be no everyday packet function which would REQUIRE the transmission of
graphics. Otherwise, we will see the network rapidly overloaded as HTML packet
gains the popularity we can expect.
Does this mean we can't or shouldn't use graphics with HTML packet radio? Heck,
no!
We'll just have to find a way to work within the limitations of the RF environment,
and do what we want to despite those limitations. That's the challenge and fun of
ham radio.
I propose that rather than attempting to modify standard HTTP/HTML protocol or
software, we define a new way to use the tools which HTML already provides,
enabling us to use graphics constantly while hardly ever having to transmit
or recieve them.
That's easy to say, and almost as easy to do.
To do this, we would set up and use a "permanent" cache of standardized graphic
filename/functions which incoming HTML can call upon and use, in the hard-drive
of each HTML-capable packet radio station.
These read-only graphics aren't updated by new copies from other systems, and
would reside in a "standardized" directory, such as C:\P_CACHE so that HTML
packet pages written anywhere will be able to call on them.
HTML doesn't HAVE to use graphics which are transmitted along with the document itself, or which happen to reside in the standard HTML cache of recently recieved graphics. You can also point to and utilize graphic files which reside elsewhere in the recieving station's system. You must have exact knowlege of where those files are, and should be reasonably sure that the distant system's "arrl.gif" will look like an ARRL logo, for example. The graphic's filenames must indicate their look or function, so I refer to them as filename/function pairs. I propose the disk directory C:\P_CACHE as the standardized location.
This opens up the possibility of enjoying some graphics even in our stream of monitored packets such as node ID's, DX Spots, gateways and BBS mail-for beacons since these graphics would be very fast, by virtue of never having to be transmitted from one station to another. In fact, stations with no HTTP protocol capability ( such as a node EPROM ) could still utilize P_CACHE graphics in their beacons, prompts, ect..
I'm not proposing the graphics themselves be rigidly standardized, but obviously
the graphics included in client software or in an update should closely match
the filename/function pairs they are associated with. After that, though, it
would be up to the user as to what his personal copy of "C:\P_CACHE\bullet.gif"
or "bground.gif" or even "arrl.gif" would look like, since these files are not
updated by other systems.
Again, what I am proposing is to standardize a set of useful graphic
filename/function pairs which would be available to all incoming HTML packets,
by virtue of residing in the C:\P_CACHE directory. Here are some useful
filename/functions which come to mind:
bullet, star, new, mail, mailfor, bbs, node, gateway, chat, arrl, ares, races, nts, amsat, sysop, help, menu, dos, dwnload, upload, reply, listnew, listmine, readmine, wxalert, news, notice, sparks, tower, radio, beam, key, computer, aprs, ect..
Those are just examples, and are not intended as a serious listing.. Some are
there which we could do without, and more have been left out, overlooked or
poorly named.
For such a standardized list to be useful, filename/functions should be defined
which will cover all of the standard servers and activities which packet ops are
normally involved in. There are just over thirty filename/functions listed above.
In all likelihood, a list of fifty should cover most of our needs, and should be
arrived at by consulting hams who are involved with the different servers and
activities.
Since use of the P_CACHE doesn't require any software changes, the service should
be available to anyone who obtains a copy of the graphics with their standardized
filename/functions and places them in the C:\P_CACHE directory. Given a listing
of the standard graphic filename/functions, an enterprising ham could even "roll
his own".
HTML allows alternate text for systems which can't handle graphics. Packet ops
with no P_CACHE would see the alternate text in their place.
By standardizing the P_CACHE directory and it's contents, we will be making a basic set of graphics available for everyday use which will have almost no time or network loading penalty associated with them.
Besides the 50 +/- "standard" filename/functions, local packet ops and sysops could distribute additional P_CACHE graphics to cover their local servers and functions. These graphics would then be "no time/spectrum penalty" graphics as well for their local users.
P_CACHE would work in addition to the standard HTML cache setup, so special
graphics CAN be transmitted and added to anyone's regular HTTP/HTML cache as
usual. If a BBS SYSOP wanted his "bullets" to look like ARRL logos, for example,
he would use his own unique filename-function "arlbulet.gif" which would be
transmitted in turn to each of his users and go into their HTML caches normally.
He could be smart though, and use "C:\P_CACHE\arrl.gif" in place of "bullet.gif"
and get the same effect without having to update anyone's cache, even first-time
connectees! There's room for creativity there, for the creative types.
Due to the lack of time/spectrum penalty associated with the use of P_CACHE, it is possible for packet ops to utilize sound and animation files as well. This probably represents our only realistic hope of using these features on packet radio in the near future.
Besides being educational and fun in itself, HTML packet radio will also serve as a strong motivation for hams to contribute to upgrades of their local network. Simply put, the hams with the faster networks will have better graphics. Using the P_CACHE lets us "get our foot in the door", providing a basic level of graphics to all users of packet radio, even those with marginal links. This will generate interest among a large group of hams who currently lack a clear motivation to see the network upgraded, and make more resources available to those who advocate high speed. It's easier to understand "better graphics" than it is to understand technical arguements, and "better graphics" will generate a wider, more positive response in the general packet radio community.
First, though, we need to "get our foot in the door" with the introduction of HTML packet radio! When we do, it's my hope that P_CACHE will make HTML packet more fun and more usable to a greater number of hams.
If you would like to see a live demonstration of P_CACHE in action, try this:
1. Create a new directory on your computer's primary HD, named P_CACHE ( Usually C:/P_CACHE )
2. Place any small GIF graphic file in the new directory, then rename the file as TEST.GIF
3. Connect to this article again on Internet, and Refresh this page on your browser, if necessary. At this point, your graphic should appear immediately below here.
If you tried out the test/demo above, you saw something unusual on the Internet,
in that YOUR graphic appeared on MY Web Page. To that extent, you are in direct
control of this page's appearance on your browser. Now imagine being able to
control the appearance of basic HTML graphic components such as background
graphics, bars, pushbuttons, bullets, logos, ect. You can use P_CACHE graphics
from any source, or you can create or modify them yourself, to reflect your
preferences. So, while P_CACHE is primarily intended to serve as a low/medium
speed solution for HTML packet radio, it also allows users to "personalise" the
look of HTML packet radio on their browsers.
A second use for the P_CACHE directory would be to locate the files for our
personal "Ham-Pages" there, so other hams will always know where to have their
browsers "look" for your page upon connecting to your station.
file:/P_CACHE/INDEX.HTM for example, as a standard place to 'look" for those files..
Thanks for taking the time to look and think this proposal over! - Charles N5PVL
Contact: