Public SourceMage Discussion List

[Juuso Alasuutari <iuso AT sourcemage.org>]

On Friday 14 April 2006 23:40, Seth Woolley wrote:
> 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.

Well, yeah there are probably other ways to achieve "that authentic 
server-client feeling" during cast and other operations. Right? As lost as I 
am with technical words, I hope the bottom line is somewhat agreed on: to be 
able to go back to the previous question, and to be able to easily implement 
different (g)uis that make use of sorcery's power, and the possibility to 
write scripts which talk to sorcery - these would rock. Please correct me if 
I'm not talking about the original idea anymore...

Proper testing is of course a token, or at least should be. If and when 
sorcery evolves towards something like this, I'm the first hobo on the block 
begging for spare hardware on which to run testing stuff...

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

Of this I think I understand most of what's said.

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

This I really don't get. But I don't think that matters at this point.

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

I feel stupid for not having a go at delve so far. But what you're saying 
sounds good. But it also sounds like it needs a more detailed roadmap. Me and 
David are guaranteed to help out once we know how.

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
3) The first query (config_query VAR1 yadayada...) is presented. The ui that 
does this can be anything basically)
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
5) Now the next prompt is presented, "next" meaning "the one following the 
prompt which sets VAR1"

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

Juuso