Re: messages from the WWW Library

Aleksandar Totic <totic@milton.cs.uiuc.edu>
From: Aleksandar Totic <totic@milton.cs.uiuc.edu>
Message-id: <199307060000.AA19203@milton.cs.uiuc.edu>
Subject: Re: messages from the WWW Library
To: www-talk@nxoc01.cern.ch
Date: Mon, 5 Jul 93 19:00:33 CDT
In-reply-to: <9307052243.AA19340@stat1.cc.ukans.edu>; from "Lou Montulli" at Jul 5, 93 5:43 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO

> 
> What do you developers think about changing all of the informative
> user messages that currently come out of the WWW library into some
> sort of standard user_message call.
> 
> Currently there are several modules that use differing forms of user
> messages when they are in use.  HTNews uses NEWS_PROGRESS or some
> such define which is defined to be a "printf".  HTAccess uses either
> "printf" or user_message.  If all of these messages could be expressed
> using the same routine my life would be alot simpler.  I suggest
> using something like "HTinfo_popup" or "HTuserMessage" or something along
> those lines.  The client could define "HTuserMessage" to be just a
> "printf", or a popup window or a statusline message.
> 
I think that this is a great idea, especially in GUI environment where
printf does not really work. The error messages are scattered
all throughout the code, which makes them hard to modify for a
particular platform. What I would also like to do is give user the
opportunity to correct an error.

For example, when a file ends in an unknown extension, user should be
able to specify how does he want to parse it, save it to the disk,
etc. Or when anonymous ftp refuses connection, user should be able to
try again with a different password. Right now making any choices
inside the WWW lib is hard.

I would like to see a substitute for a printf method that is flexible
enough to support useer input. The ideal interface would be something
like this:

The error routine is void * ErrorAlert(short errorNumber, ...).
Arguments following errorNumber are equivalent to printf. All the errors,
and their reasons would be declared in a header file. There, arguments
expected for each type of alert would be listed, as well as arguments
expected to be returned from ErrorAlert. In case when user can take
action upon error, an argument returned from ErrorAlert would specify
the action to be taken.

This would give programs that use the library flexibility we need so
that we do not hack the insides of its code.

Aleks