DragonFly BSD
DragonFly kernel List (threaded) for 2004-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Goals for first release (June/USENIX)

From: Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>
Date: Fri, 12 Mar 2004 16:09:57 -0500

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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]