Public SourceMage Discussion List

[Robin Cook <rcook AT wyrms.net>]

I guess depends will have to be a bit more specific rather than relying 
on the depends of spell it depends on, or the trigger won't catch them all.

CuZnDragon
Robin Cook

-------- Original Message --------
Subject: Re: [SM-Discuss] Improved Sorcery Trigger Support
Date: Sat, 3 Sep 2005 17:02:39 -0700
From: Andrew <afrayedknot AT thefrayedknot.armory.com>
To: sm-discuss AT lists.ibiblio.org
References: <20050826034036.GA30079 AT thefrayedknot.armory.com>


Hi, given the recent concerns over the openssl update I decided
to go ahead and implement the solution I outlined below in devel
sorcery. Disclaimer: this is in the "proof of concept" phase, its not
completely ironed out, Im adding it so other interested parties can try it
out and we can iterate on improvements if need be (bazaar style). Swoolley
is going to update the openssl spell in test grimoire to try this out.

from the spell maintainers perspective you add a file called "UP_TRIGGERS"
(for lack of a better name), in it you call a function called "up_trigger"
for each spell thats going to break due to an abi change (or whatever).

Heres a brief example:
for each in $(gaze depends $SPELL 1|cut -f1 -d:); do
  up_trigger $each cast_self
done

This is almost exactly the same as placing a TRIGGERS file in each of
the spells that depend on openssl, but hopefully easier.

from the users perspective the following will happen: all the spells
that depend on openssl (in this case) will automatically get added to
the list of spells to cast. Hopefully after cast completes there wont
be any spells broken due to ssl update; thats the goal at least.

-Andrew

> * Add a new spell file on the triggerer's side. The file would let the
> spell generate triggers. For example, zlib could dynamically trigger
> cast_self on all the spells that depend on it. Other spells with similarly
> shaky api's could do the same. Perl could trigger a recast on all the installed perl modules. 
>
> Commentary: Much more powerful interface. However it involves making
> (possibly bad) assumptions about spells. Leads to further decentralization
> of information, for example, the triggerer would have to know what spells
> may be effected by an api change. Overall spell management could become
> more difficult.

--
__________________________________________________________________________
|Andrew D. Stitt                           | astitt at sourcemage.org    |
|irc: afrayedknot                          | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus    | acedit at armory.com        |
|Sorcery Team Lead                         | ftp://t.armory.com/         |
--------------------------------------------------------------------------
_______________________________________________
SM-Discuss mailing list
SM-Discuss AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/sm-discuss