[Tfug] Poor man's GUI

[Bexley Hall]

Hi Don,

On 3/11/2014 1:22 PM, Freeman, Don wrote:
> One issue you may want to think about is when I do a saveas on a webpage,
> the user gets to specify the file type, html, txt, or mht. You will need to
> tell him in advance what file type to choose as the results are very
> different.

Yes.  I think it simpler to just say "Save".  This has the side-effect
of preserving the "current settings" as a starting point for the next
invocation.

> Also, how will you trigger the saveas? If it's from the browser
> menu, many users have that menu hidden and would be without a clue how to
> "show" it.

Different type of users.  I'm thinking more along the lines of
replacing the slew of .rc files with HTML documents.  So, instead
of a bunch of settings of varying syntax -- with "comments"
interspersed (comments having their own syntax that seemingly
varies with each file!) but not firmly *tied* to the settings
that they are intended to document.  You can expect a certain
level of competence from the user -- but not necessarily
*expertise*!

For example, a user EDITING such a file can deliberately or
accidentally alter or relocate a comment that was originally carefully
placed where it was.  And, the next person to dig through the file
has no idea that this has occurred.  With the browser.save approach,
all the user can do is alter *values*/choices; the "commentary" remains
intact.

So, inetd.conf(5) can be *littered* with lots of commentary regarding
the various services enabled/configured therein.  But, all the user
can do is turn them on/off and/or alter certain options for each.
There's no risk that he'll move the telnetd entry to some other place
in the file (as seen *through* the browser) distant from the commentary
*for* that service.

It also lets the form of the configuration options be altered
away from the rigid form prescribed in inetd.conf(5).  E.g., you
can have a checkbox labeled "debug mode" for the telnetd(8) entry
instead of forcing the user to remember to specify "-D <level>"
as part of the "telnetd command line".  And, perhaps a little
*table* in the HTML that clarifies what each <level> supports.

So, instead of being required to have vi(1)/ed(1) *and* man(1)
up and running, you require the browser to be operational
(but not an HTTPd!).

And, you avoid all the buggy/variable configuration file parsing
code for each "app" (comments not allowed; comments allowed
anywhere on line as long as preceded by '#'; comments only allowed
at start of line; lines end in \n; lines MAY end in CRLF;
missing \n on last line is/isn't an error; whitespace ignored
everywhere; whitespace NOT allowed; only tabs allowed as field
separators; case sensitive/insensitive; etc.)

What a mess...!

--don