Re: Goals for first release (June/USENIX)

[Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>]

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.


Andrew.