Public SourceMage Discussion List

[Seth Woolley <swoolley AT panasas.com>]

oops, meant to reply to all...
--
Seth Alan Woolley
Software Engineer
Accelerating Time to Results(TM) with Clustered Storage

www.panasas.com
swoolley AT panasas.com
510-608-4382

--- Begin Message ---

• From: Seth Woolley <swoolley AT panasas.com>
• To: Juuso Alasuutari <iuso AT sourcemage.org>
• Subject: Re: [SM-Discuss] minimize global effects in CONFIGURE and DEPENDS (Was: Using dialog for the net-conf spell)
• Date: Fri, 14 Apr 2006 13:39:42 -0700

Juuso Alasuutari wrote:

On Friday 14 April 2006 15:31, David Kowis wrote:

I was thinking something about this a bit earlier. Mostly because I find
it really annoying to make one mistake and have to restart everything
again.

An API could be developed to seperate the backend from the front end.
It's not a small task, however. It would require changing the way things
worked. config_query wouldn't ask the question, but would instead return
the pieces needed to build the question, the answers, and a short
description. Then those would be given to the front end, whatever front
end library we've written, and it would formulate the question. Whether
the frontend be the same thing we've got now, or a dialog, or a gui.
Same thing would have to happen for most of the stuff in configure.

It's not a small task, and I've not quite had enough time to think about
it. Optional_depends really throw the process a bit because they can
change the dependency tree completely.

Anyways, I think that's more of an ideal solution than simply catering
to dialog. It also requires the most work....

Highest quality indeed requires the highest sacrifices.

I like this idea, because it would free cast/sorcery from its somewhat restricting be-all mentality to be what it's meant for, a steady foundation to base better UIs on.

It would also mean that eventually we could be able to simultaneously develop a few graphical frontends (dialog/ncurses, GTK, QT) alonside the text-based one without having to continuously reinvent the wheel.
What excites me even more is the possibility of efficient cast scripting. When you could write a frontend that acts on automatic, creating a powerful desktop install system based entirely on sources would be possible. I think that would be a first in the history of Linux...

Since we are now touching the whole sorcery philosophy of doing things, I assume this will also be a philosophical discussion. I'll add my log to the fire with my wish that when SMGL 2.0 is out, we'll have a server-client kind of sorcery with at least three frontends to choose from, and an installer that the World has never seen. :)

I don't think we need a complicated server-client distinction implemented in config_query. We can override config_query* easily already, it's just the code around the config_query that can lead to problems. I think we need a cli that merely has well-defined hooks that we 1) audit and 2) promise not to change frequently. The audit is so we get the problems out of its use before we give a blessing to freely use it.

Eliminating global effects during dependency resolution are all we really need to untie the interface from a one-pass-only interface. It's that simple change from one-pass-only to "we can go back if we need to" that enables the gui interface, because the gui interface philosophy is "let me experiment and go back, commit last.

If we enforced restrictions on global effects by using installwatch to monitor what happens during configure and depends resolution on the filesystem and checked the environment before and after for bad things that's an optional feature that developers could turn on to lint-check things.

Writing a front end that wraps around sorcery then is a piece of cake. What we have works. Don't forget that we already have the delve tool that increases scriptability tenfold. Let's try and minimize the actual changes we make to the current setup.

--
Seth Alan Woolley
Software Engineer
Accelerating Time to Results(TM) with Clustered Storage

www.panasas.com
swoolley AT panasas.com
510-608-4382

--- End Message ---