Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

On Sun, Apr 16, 2006 at 11:51:38PM +0300, Juuso Alasuutari wrote:
> I've been thinking about David's idea for the last two days, and I have 
> some 
> kind of vision how cast could handle user interaction. I have very limited 
> understanding of sorcery as a whole, so this might be far off, but bear 
> with 
> me anyway and please tell if it's a realistic idea.
> 
> 1) Cast starts processing a spell file which requires interaction, e.g. 
> CONFIGURE
> 2) The file is read from top to bottom without stopping; config_queries 
> don't 
> ask anything themselves, but only give cast information about what 
> questions 
> are to be asked and what variables they set

This is not the way it works now.  This is what could be done in the future
(except it wouldn't be "cast" that did it, it would be your abstraction layer 
or 
some hook in sorcery to allow your abstraction layer to override the 
functions).

> 3) The first query (config_query VAR1 yadayada...) is presented. The ui 
> that 
> does this can be anything basically)

Why not expose all queries at once since you've got that info at this point?

> 4) After an answer is received from the user, part 2) is run again, so that 
> possible "if [[ VAR1 == x ]]; then config_query..." options are revealed

Yes

> 5) Now the next prompt is presented, "next" meaning "the one following the 
> prompt which sets VAR1"

see my response to 3.  Instead of going to the next prompt, you redisplay the
options to expose new changes until they decide they are done.

> 
> And so it goes on, until all prompts have been answered. The same happens 
> with 
> DEPENDS, and of course you can also later return to CONFIGURE after you've 
> left it.

DEPENDS is more complicated.  Go for CONFIGURE first, see how well it works 
and
then look at DEPENDS (which will need a bit more thinking).

> Of course this kind of system means that you would have to strictly 
> restrict 
> user interaction to specific spell files (almost done already), and allow 
> no 
> other scripting in them. At the moment I believe PREPARE is allowed to have 
> both, so it couldn't be sourced multiple times like this.

Yes, we need stronger policies and checks in place to make this realistic.

> 
> Juuso
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss