Goals for first release (June/USENIX)

[Andrew Atrens]

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. 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/


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.


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.


Any well-designed protocol will give you this, though.

And in fact a badly designed XML schema could probably break it too :)
Good design, bad design. Whether you are using xml or a c-struct, or 
even bytestring interface a hammer in the hands of a monkey is still a 
hammer :) :)


-Chris