Wish List Item - "Public" file name

[Fairlight]

This public service announcement was brought to you by Scott Walker:
> 
> 2) On file....   This is totally meaningless message to the average user
> of my application.  Yes otsarcrheadunp is the name I gave the file and I
> know what it means.  A user has no freaking idea what it means.  In my
> mind, that makes is a bad message.  I would like it to use the "public
> name" that was specified in ddefine.  So it would say:
> 
> "File:  Accounts Receivable Cash Receipts Entry"

OTOH, the enduser not knowing what the hell is going on can be a good
thing.  One, they won't try to fix it themselves (which usually tends
to lead to disaster).  Two, it's guaranteed revenue if you charge for
support--you get paid to fix what's wrong--even if it's fP's fault.  Three,
it's an obfuscation layer between issue and code endpoint; you have to
interpret what file it is when, as a developer, you know more immediately
from the file and path where the -exact- problem lies.  You can't have two
files with the same accidentally identical public name.  The "real" path
tells you everything you need to know, and in my opinion, as a developer,
it tells the end-user as much as they need to know already:  that they need
to call you, and where the fault point is reported as being.

On the subject of errors, I'm of two philosophies after many years of
end-user exposure:

1) Give them enough information to be able to get the -developer- to the
right place as fast as possible with no cause for error.  This is why I use
numeric exit codes yet:  Tracing Error 17 is easy, I just search for
fl_die(17) in the code.  It's only going to appear once.  :)  Adding any
relevant diagnostics to the information is a bonus, and I strive to do
that.  Anything that makes debugging easier is a better thing.  But
debugging is best done by developers, not by end-users.

2) "No user-serviceable parts inside."  They're end-users, don't even let
them think it's possible to fix it themselves unless it's a subsystem you
specifically designed to be user-fixable.  I have such subsystems and
provide facilities for it where applicable.  But a hard error is not
something the end-user should be messing about with.  It's something they
should be getting the correct party in for, before a mess is created.

Just my take on it.  I respect your wish list, I even understand your
rationale.  Our takes on it just differ, and I put this forth as an
opposing, balanced view for evaluation.

> 	"Waiting for 'otscust1' record 1 to be unlocked"
> 
> Once again this message is way too cryptic for a user to receive.  Users
> don't know what the heck this means.  Sometimes they kill the posting
> process by clicking the quit "X" on their telnet program, thus creating
> a mess.  Using the public name for the file, at least we could say:

If they're killing the telnet program in such a fashion (or at all) because
of an error like that, I'm sorry but they haven't been given enough
training.  That's just ignorance, and ignorance is best cured by education,
not by altering the way the world works to enable their ignorance further.
Maybe people can get away with it nowadays, but back when I was office
temping, one could get fired for being that stupid and further fouling the
works.  It appears that actual consequences for the responsible ignorant
user have all but vanished.  Why enable the trend further?

> Anyhow that's all.  I would love to hear others thoughts on this.

Well, there are mine.  I hold dissenting views.  Sorry, but I do.

> BTW, who do I send this to at fp for wishlist consideration.

I thought it was wishlist at fptech.com.  That or it's that wish list that
Howie maintains, but I don't remember the URL.

mark->