Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Improved Sorcery Trigger Support

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

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


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




Archive powered by MHonArc 2.6.24.

Top of Page