SourceMage Grimoire Bug List

[bugzilla-daemon AT bugs.sourcemage.org]

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.