Skip to Content.
Sympa Menu

sm-grimoire-bugs - [SM-Grimoire-Bugs] [Bug 8936] New: grimoire/sorcery compatibility checking

sm-grimoire-bugs AT lists.ibiblio.org

Subject: SourceMage Grimoire Bug List

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-grimoire-bugs AT lists.ibiblio.org
  • Subject: [SM-Grimoire-Bugs] [Bug 8936] New: grimoire/sorcery compatibility checking
  • Date: Thu, 19 May 2005 13:25:30 -0700 (PDT)

http://bugs.sourcemage.org/show_bug.cgi?id=8936

Summary: grimoire/sorcery compatibility checking
Product: Codex
Version: devel grimoire
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Unknown
AssignedTo: grimoire AT sourcemage.org
ReportedBy: acedit AT armory.com
CC: eric AT sandall.us,sm-grimoire-bugs AT lists.ibiblio.org


As time goes on there will be new functions added to libapi, one example is
unpack_file, which is part of the new gpg checking in spells. In a perfect
world
most people use stable grimoire and use the latest stable sorcery and it all
works together. However, in our non-ideal world, most people use test grimoire
and some version of stable sorcery, not necessarily the latest and greatest.
Believe it or not, in my experience not everyone uses the latest stable or
even
updates when a new one is released for whatever reason.

New sorcery releases may have new functionality available, however spells are
left with the problem of when to start using the new functionality. You cant
start using the functionality until its widely available, we dont know if the
functionality truly works until its widely used. This presents a chicken/egg
problem. If you start using new functionality in a spell before everyone's
updated, then they may get strange errors. We need some sort of protection
against sorcery and the grimoire getting too out of sync.

I would like some effort to be placed on defensive programming in spells. The
end result should be that new functionality can be adopted more agressively.
Spells can adopt new functionality sooner rather than just hoping everyone has
updated.

Heres the main idea, have some facilities to sanity check that the
functionality
we want really does exist before trying to use it in a spell, if the
functionality isnt there, either print an informative warning (update sorcery)
and gracefully fail, or fallback to some previous behavior. This code is
intended mostly as throw-away code in transitionary periods.

For example, spells are going to be using the new gpg checking code in sorcery
and calling the new unpack_file api. It is nearly trivial to write a sanity
check for this in PRE_BUILD:

if ! declare -f unpack_file &>/dev/null; then
message "update sorcery ..."
return 1
fi

This could easily be incorporated into the FUNCTIONS file, its an opt-in
solution for spells and can be temporary code for transitionary periods.

top of PRE_BUILD for spells wanting to use unpack_file:
# remove in two month (5/19/05)
check_for_function unpack_file || return 1

An alternative is to use declare -f as an #ifndef operation:
declare -f unpack_file &> /dev/null ||
function unpack_file() {
message "update sorcery..."
return 1
}

Then if a spell attempts to use new functionality on an old sorcery it wont
work. I can maintain the list of new-additions in the grimoire myself so its
little work for the grimoire maintainers.

Another interesting and more global hammer, which is possibly more useful for
stable grimoire releases, is to have a known file/function somewhere in the
grimoire (or in individual spells) that does a sanity check on the current
version of sorcery, and if the sorcery version is "too old", sorcery refuses
to
use that spell/grimoire. The stable grimoire releases could enforce a minimum
sorcery branch to run, the devel grimoire could require people to use devel
sorcery.

This might seem like overkill or a silly/ridiculous thing to do, or we could
just say "you must use the latest sorcery with the latest grimoire or it wont
work/we dont support it" but honestly I dont think thats helpful or in the
least
bit robust, at least from a quality standpoint. Not all users are going to
just
know these things and if they hit those problems it reflects poorly on us.
Most
of the compatibility issues are currently minor, but the future is unknown and
these sorts of things you cant always fix in hindsight, so i'd like to have
some
way to set this up now rather than when its too late.

--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



  • [SM-Grimoire-Bugs] [Bug 8936] New: grimoire/sorcery compatibility checking, bugzilla-daemon, 05/19/2005

Archive powered by MHonArc 2.6.24.

Top of Page