Goals for first release (June/USENIX)

[Chris Pressey]

On Thu, 11 Mar 2004 00:21:42 -0800 (PST)
Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:

>     Those are my personal goals.  Others can post their own personal
>     goal set for the first release.

"Team Cruft Removal" (that's me) would like to see the ``register''
keyword eliminated from at least usr.sbin, and *maybe* usr.bin, by
release time.  :)

I'd also like to see some other things disappear:

	- sysinstall (replaced with our installer, of course)
	- its pal, libdisk
	- send-pr (replaced by some bugzilla client prg?)
	- the 'old' mkdep (unused AFAICT)
	- probably some other little things that escape me right now

. ..

Regarding packages, there was a small brainstorming session on them on
IRC.  I'm fairly neutral on most aspects of it, but one thing did come
up that also affects the install program and possibly other parts of
DFly eventually, so I should mention it: the UI.

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.

The transport layer(s), I really have no strong opinion about.  I'm
currently thinking that libcaps will already be there anyway, and it
gives us a means to encode C structures now too.  (although that, too,
will require bindings if we want to access it from Python...)

The protocol, OTOH, I *do* have strong feelings about.  It *must* be
abstract.  The backend says things like "display a menu to the user now"
and waits for the frontend to respond with "ok, the user selected menu
item 'foo'."  There should *not* be messages like "Create a button in
the upper-left corner of the window."  That's not nearly abstract
enough.  We need to deal with the user on a level *above* widgets.

A brief google reveals that there is a lot that has been done on
abstract user interfaces, but I daresay it's just overkill for what we
need.  But if anyone has any suggestions for something that's already
established, that fits our needs, I'm quite eager to hear them.

Whatever route we take, I think it's important to sort this out before
too much work is done in any one area, because this is the sort of thing
that, if shared, would give DragonFly a very consistent look and feel
(and behaviour,) and this would be (IMO) highly valued by most users.

Thoughts?

-Chris