Goals for first release (June/USENIX)

[Chris Pressey]

On Sat, 13 Mar 2004 11:30:31 -0500
Andrew Atrens <atrens at xxxxxxxxxxxxxxxxxx> wrote:

> Chris Pressey wrote:
> > On Fri, 12 Mar 2004 16:09:57 -0500
> > Andrew Atrens <atrens at xxxxxxxxxxxxxxxxxx> wrote:
> > 
> > 
> >>Chris Pressey wrote:
> >>
> >>>On Thu, 11 Mar 2004 00:21:42 -0800 (PST)
> >>>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.
> >>
> >>How about using XML for the interface?
> > 
> > 
> > If there's an established DTD for it, yes.  If not, hardly any
> > point.
> > 
> 
> Not sure how this is relevant.

I'll try to explain...

When the topic of XML came up on another mailing list I'm on, the
question was raised, "What exactly is the problem that XML is the
solution to?"

There was no answer given at the time.  I've thought about it, and
there's only one major thing that I can think of: standardization.

BUT - if everyone uses their own DTD (or worse, no DTD at all), XML
clearly does not improve standardization!

> If you're going to be building a protocol 
> from scratch anyways, coming up with a dtd doesn't sound like a lot of
> work.
> 
> Check out -
> 
> http://xmlfiles.com/dtd/

OK; I've got other things on my plate, but here's a gloss of my idea for
a protocol, and if you want to write up a DTD for it, be my guest.

The primary feature of the protocol (beyond all the handshaking and
acking and stuff) is the 'present' message sent from the backend to the
frontend.  'Present' tells the frontend to present a form, in whatever
way it can.  The user can then play with the form however they want,
and submit the form back to the backend.  At which point the frontend
sends a 'Presentation finished' message to the backend, along with the
values that user left in the form when they signalled that they were
finished.

A 'form' structure is sent along with the 'present' message.  A form
consists of some metadata, zero or more 'fields', and zero or more
'actions'.  The metadata consists of the id of the form
(computer-readable and hopefully unique,) the human-readable 'title' of
the form, the human-readable 'description' of the form, and so forth.

It should also have a flag which determines whether the set of fields
specified can appear exactly once on the form (like a typical dialog
box,) or whether it can be repeated (like a spreadsheet or database list
view.)

Each field also has 'id', 'title', and 'description' properties. 
Additionally, though, it has an 'initial value' property and a
'constraint' property.  The constraint is probably a regular expression
- it would be nice if it were a full-blown predicate, but that's
definately an extra level of complexity.

Each action also has 'id', 'title', and 'description'.  It should also
have a property which indicates what steps are taken when the action is
invoked.  Doing this in a full-blown way is also an extra level of
complexity; at the very least, what is needed is an indicator that the
action is a 'done' action, i.e. it causes the 'Presentation finished'
message to be sent back.  The form's data is sent to the backend with
the 'Presentation finished' message, along with the id of the form, and
the id of the action that was selected to cause this.

With even this stripped-down system (a lot like HTML forms - except with
the one-set-of-fields/many-sets-of-fields distinction) one ought to be
able to construct dialog boxes, menus, simple fill-out forms, probably
even a disklabel editing interface.  They'd be extremely crude, but
they'd also be completely UI independent - if/when we want to switch
away from curses, to X11, or a teletype, or voice recognition, there's
been no artificial barrier set up.

> > There's AAIML, but AFAICT it's not well-established yet.
> > 
> >   http://xml.coverpages.org/userInterfaceXML.html
> > 
> > It's also waaay overkill for what we need IMO.
> 
> Yah, could be overkill. But it seems to me that it's the modern way to
> go, IMHO.

What, overkill is the modern way to go?  :)  :)  :)

-Chris