[GRASS5] Platform for next generation UI

[Russell Nelson]

Glynn Clements writes:
 > Russell Nelson wrote:
 > 
 > >  > No, I'm saying that modules should, wherever possible, work with or
 > >  > without a terminal. No writing prompts on stdout and expecting a reply
 > >  > upon stdin; that won't work if the module is called from a GUI.
 > > 
 > > Why?  It works just fine with SMTP, NNTP, FTP and probably a few other
 > > protocols.  But that's the point -- if it's really a protocol that can
 > > also be used by a person, then that's what it is.

 > Engaging in an interactive dialog with a program is significantly more
 > involved than simply running it with specific arguments.

That's the point -- if it's really a protocol which can also be used
by a person typing commands at it, then it's been designed to be
operated by another program.

"Back in the day" a Unix program would ordinarily be written to accept
commands on its stdin and write the results to its stdout.  Somewhere
along the way people lost the idea that a program could be driven by
another, and we ended up with big monolithic applications that expect
to receive keystrokes and write curses; or worse that require a
combination of keyboard and mouse input and write graphics output to a
GUI.

 > Re-working the guts of each module for use in a library which is to be
 > used by a long-lived application would be a lot of work, for several
 > reasons:
 > 
 > 1. You need much greater robustness.
 > 2. You need to make more effort to prevent memory leaks.

Urgh.  It sounds to me like you're saying that the GRASS is so poorly
written that one function needs to be protected from another by the
kernel's inter-process protection.

 > 3. You need to be able to re-initialise the state at each invocation. 
 > Currently, the core GRASS libraries use a lot of static data. This
 > data is initialised automatically at startup, and is discarded at
 > termination. For a library, you would have to be able to explicitly
 > re-initialise all of that data before invoking each command.

#1 and #2 are reasons to split functions between processes.
#3 is a reason NOT to split functions between processes.

I would argue against you, but you're doing a perfectly fine job of it
yourself.  In principle, you're not disagreeing with me.  You're just
pointing out that an artifact of the implementation would make
creation and use of a library difficult.

-- 
--my blog is at     blog.russnelson.com         | A computer without Python is
Crynwr sells support for free software  | PGPok | like a CPU without memory:
521 Pleasant Valley Rd. | +1 315-323-1241       | it runs, but you can't do
Potsdam, NY 13676-3213  |     Sheepdog          | anything useful with it.