Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Improved API for query and store config information

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Paul <dufflebunk AT dufflebunk.homeip.net>
  • To: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Improved API for query and store config information
  • Date: Sat, 20 Mar 2004 09:14:36 -0500

The reason triggers are done the way they are is because they are a last
resort. They cannot be ordered with the rest of the spells in libdepends
because they are all special cases. If they were put in with the others,
you'd start getting cycles and which would be broken and the order would
be wrong. What is the compelling need to complicate the life of
libdepends? It's complex enough as it is...

On Fri, 2004-03-19 at 22:45, Andrew wrote:
<snip>
> I've never been happy with the triggering mechanism, IMO they should
> be dealt with as follows: during the initial CONFIGURE/DEPENDS question
> period triggers should also ask the user what they would like to do, then
> according to that do something later on. I also thought that triggers
> (at least the ones that go off after a certain spell casts) should go
> into the makefile:
>
> foo : bar baz
> cast -c foo
> cast -c spell_that_foo_triggered
>
> rather than what we do now, which is bundle it all up into a call at
> the end of cast_spell.
>
> Another nice extension to triggers would be to have sorcery menu options
> for them:
> default (do whatever the default action is, always)
> yes (always do them)
> no (never do them, screw them, i hate them)
> queue (stick them in some queue for me to run later)
>
> These could also have a prompt bit set on them, which when set means that
> the user will be prompted about them with the default answer according
> to their choice of the aforementioned 4 options.
>
>
> >
> > So there is definitely some room for improvement here. An installed spell
> > should not install any new dependencies on an update unless they are
> > required. Many of the cases where on_cast/cast_self triggers are used
> > should also have on_dispel/cast_self.
> Agreed. Any other suggestions beyond what i've come up with?
> >
> > Just some observations. Not show stoppers, but will probably save users
> > (and anyone helping them in irc) from some headaches.
> I think I'll put this on my list of projects to do after the BUILD split
> stuff gets taken care of. Or maybe before depending on how motivated I
> am ;)
>
> >
> > Too much sun today ... I apologize if this makes absolutely no sense. ;-)
> makes perfect sense to me.
>
> -Andrew
--
De mortuis nihil nisi bonum.

Attachment: signature.asc
Description: This is a digitally signed message part




Archive powered by MHonArc 2.6.24.

Top of Page