On 2 Oct 2000, Jason L Tibbitts III wrote:
> It is possible to get clever, but if we were to do anything special with
> '>' quoting, I would prefer that we pretend that it isn't there
At 12:28 AM 10/2/00, Roger B.A. Klorese wrote:
>Yes, that's what makes sense.
I disagree: People reply to confirmation tokens by quoting the
entire message and tacking "accept" on to the end. If you read
quoted stuff as plain commands, you'll parse the entire confirmation
text and FIND things like sample unsubscribe commands. Bummer!
>But for my typical AOL user,
><< subscribe foo >>
>and
> subscribe foo
>are the same. (And when the error message has that silly
> >>>>> << subscribe foo >>
>look to it, they really freak.)
Then what we REALLY need is a better error reporting module! I've thought
for some time that syntax suggestions in the error msg would be better
than looser parsing rules to avoid the syntax problem.
For example, the error module COULD look for leading "<<" and
mention that AOL quoting which encloses commands in double angle
brackets can prevent the command from being parsed.
For another example, if the "subscribe" command doesn't have an email
address but the very next line IS an email address without a command,
the user now gets two error messages that aren't merged into one
suggestion of "your command may have been broken into two lines,
so here's how to use a backslash to avoid that problem".
Try sending "subscribe listname@xxx.com user@xxx.com" where "xxx"
is replaced with the domain that your server actually runs on. BOOM.
This is a case where the command parser could be taught to ignore
domain names attached to list names, OR the error module could
detect an extra "@" and remind the user that domain names only
go on email addresses (not the listname field).
Perhaps you could also compile a list of error message improvements?
Follow-Ups:
References:
|
|
