DragonFly kernel List (threaded) for 2004-03
Re: Goals for first release (June/USENIX)
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? Provides a whole of flexibility
and even a fair amount of backward compatibility (newer UIs could talk
to older backends - they (the backends) would just pitch any new
commands/attributes/groups they hadn't yet learned of. Older UIs on the
other hand could talk to any same or newer backend.
From a front-end point of view there's xml bindings out there for just
about anything you'd want to use as a UI.
From a backend (agent) point of view you could easily do C, or Perl.
XML doesn't care about the presentation of the data, just the data
itself. It would be up to the UI to worry about displaying the data,
asking for user input, that type of thing. So, following an MS analogy,
the 'wizard' logic would be in the UI, get/set-edit/create/command would
be passed as XML formatted messages, and you'd get XML formatted
asynchronous responses and status reports arriving back from the agent.
Keeping the interface asynchronous buys you a lot of flexibility in
UI-wise, I think.