Re: [Sheflug] GUI vs CLI and config file formats

[Martin P Holland <nospam [at] noether.freeserve.co.uk>]

On Tue, 13 Jun 2000, Stephen J. Turnbull wrote:

>There is nothing that XML can do that "flat ASCII" can't.  Take
>~/.emacs as a classic extreme example; Emacs-Lisp is in no sense a
>standardized language, except by long usage.  Many much less
>formalized "configuration languages" also are very successful;
>consider .procmailrc.

This last point is possibly exactly my point. Everyone has there own really
cool configuration file format. Total anarachy. This is a bad feature of unix.
There should be a more standardised format that is flexible enough to deal with
all cases. xml may or may not be it.

>What makes XML and similar techniques important is the possibility
>they show for supporting new paradigms through a standard
>meta-language and via plug-in components for the developers.  This
>will hopefully allow the developers to concentrate on the desired
>semantics and reliability, rather than on just "getting the user's
>settings out of the bloody .rc!"

No arguments.

>Unfortunately, and what I am complaining about, far more attention is
>paid to the "G" than to the "UI".

I agree. Quite often when a new GUI project is announced and you go to their
page to download an early version you find the functionality of the app is
totally absent but all the menubars etc are there just as in the final version.

>    Martin> Well kppp does grovel through /var/log/messages but the
>    Martin> clues there with default syslogging are usually
>    Martin> minimal. And in any case with fuller debugging it's still
>    Martin> a highly nontrivial task.
>
>Right; what I meant was that kppp should automagically set the
>debugging higher, and help to produce a bug report.

No No No! It should diagnose the problem. There should be no sending of reports.
Noone should be wasting time reading ppp logs. If linux has 100 million users
the newsgroups will be unsuable if they are packed with people posting ppp
log files.

>    Martin> AFAIK the failrly puny attempt that kppp makes is superior
>    Martin> to that made by any other app GUI or CLI so it's seems
>
>Have you looked at Emacs with its doctrings, apropos, the ability to
>find the file any function was loaded from, copious Info files, and
>Custom?  All the stuff that Al says "could be done" I've used on a
>daily basis for decades.  It happens that I currently favor XEmacs,
>the semi-GUI black sheep of the family, but all of that stuff has
>always been available in the GNU Emacs family.

Sure. It turns out that emacs is not my favorite editor and info not my
favourite documentation format but I can see that worthy efforts have been made.
However, newbies will never fire up emacs so this is besides the point.

>    Martin> churlish to criticise them too strongly, given a daunting
>    Martin> task and one that nonone else can be bothered to take on.
>
>I don't mean to single out kppp for criticism, really.  The point is
>that if they are best of breed, and yet "fairly puny", and noone else
>can be bothered to try that hard, that doesn't say a lot for the rest
>of the industry.  That's the problem.

No. This is not a GUI problem at all. The pppd developers should be coming up
with auto-diagnostic tools. 


>on something rather different:
>
>    >> And why doesn't the GUI package all that information up into a
>    >> nice mail message you can address to the help channel of your
>    >> choice?
>
>    Martin> The issue here is decoding the meaning of the detailed
>    Martin> logs. There is currently no automatic system in place for
>    Martin> this, just the mumblings of gurus in the
>    Martin> newsgroups. Mailing hyper gibberish to people is no
>    Martin> different from telling them to read it in a file.
>
>It is if they can't read the file because it's on a different system.
>The problem is getting the log data and the config into the hands of
>the expert.

Again, I say that there should be no mailing of log files (or at least only as
a last report). The gurus who interpret the logs are following some algorithms.
So should the program.

>    Martin> The effort here needs to be directed to decoding the log
>    Martin> into a fixable problem.
>
>Not according to all the "how to report bugs" files I've ever read.
>They all emphasize sending the logs, the error messages, and the
>config verbatim, and discourage attempts by the user to "decode" them.

Don't disagree with that. The experts should be doing the decoding and the
experts' knowledge should be encapsulated in the program.

atb

Martin
-- 
http://www.shef.ac.uk/~pm1mph



---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.