Goals for first release (June/USENIX)

[Chris Pressey]

On Thu, 11 Mar 2004 23:27:16 -0500
Rahul Siddharthan <rsidd at xxxxxxxxx> wrote:

> Chris Pressey said on Mar 11, 2004 at 20:18:01:
> > Regarding packages, there was a small brainstorming session on them
> > on IRC.  I'm fairly neutral on most aspects of it, but one thing did
> > come up that also affects the install program and possibly other
> > parts of DFly eventually, so I should mention it: the UI.
> > 
> > There's a general feeling that the UI should be abstract.  That is,
> > we shouldn't tie ourselves down to one sort of interface (like
> > curses.) The frontend and the backend should be seperated, so that
> > different backends (package manager, installer, etc) can use
> > different front ends(curses, web interface, etc.)
> > 
> > There's a couple of ways to go about this.  We could use an API -
> > but that ties us into a particular language (or set of languages
> > that implement the bindings.)  I think it would be better to use
> > IPC.
> 
> What's wrong with command-line tools, and building graphical
> front-ends (if required) for these tools?  To me that seems more like
> the "Unix way".

Absolutely nothing.  In fact, I don't see where there's a conflict.

The thing is that, if we're going to have a user interface at all -
which is pretty much mandatory for the installer, and which several
people have said they'd like to see for the packaging system - then
there are some compelling reasons for it to be seperated from the logic
behind it.  The reasons for it being seperated into two different
processes which use IPC are even more compelling IMO.

One reason is that each process, the backend and the frontend, has a
slightly different idea of state.  If they're two different processes,
each can have their own state.  This can make using the frontend a
smoother experience for the user - for example, no flickering and such
artefacts that you'd have from calling 'dialog' every so often in a
shell script, where the logic and the ui are essentially sharing the
screen.

One other reason is because it's extremely awkward to have the frontend
be a CGI or PHP script without any control logic in it *without* doing
some IPC like this.  It's a matter of what drives what - using 'dialog',
the script drives the UI by calling 'dialog', but using a CGI, the user
drives the script by issuing HTTP requests.  IPC would level the playing
field here, letting us use the same backend script for both.

This is no way prevents a backend (or a frontend) from being written in
the "Unix way" as a shell script, as long as there are utility programs
that can do the IPC.  (This is really just another kind of binding.)

And of course power users will forego the user interface entirely,
that should certainly still be possible.  If not, we're really designing
something wrong somewhere.

-Chris