Giving multiple groups land access: Is there a better way?

In a Resident Answers thread (/327/6b/235872/1.html), we kicked around benefits and approaches for giving multiple groups access to a controlled parcel. I suggested a script that augmented the access list by testing the (tagged) group membership of sensed avatars. This has a few obvious disadvantages:

1. The avatar-sensing object being set to a different group than the land would mean that either auto-return would have to be disabled on the parcel, or the sensing script would have to be on a different parcel and communicate with the access-controlling script on the main parcel. (That "different parcel" DMZ is probably useful anyway, to ensure there's a place to land while the visitor is being sensed and added to the access list.)

2. Visitors would have to remember to wear their group tag the first time, to get on the access list.

3. Ejecting group members wouldn't deny them access automatically, if they'd ever visited before.

Probably other stuff, too.

So I sketched out a pair of scripts. They seem to work, with very cursory testing.
__________________
Parcel Access Updater

// License granted: Creative Common - Attribution (CC by)
// by Qie Niangao, 2008
//
// This script listens for new avatars whose access has been approved
// by the "parcel access sensor" script and adds them to the allowed list.
//
// The object containing this script must be on the parcel where access is to be controlled, 
// and owned by the parcel owner (which means, for group-deeded land, the object containing
// this script must also be deeded to group).
//
// For security, all the objects containing these scripts must be created by the same person.

integer REGISTRATION_CHANNEL = -1443885244;
float ACCESS_DURATION = 0;  // Hours after first sensing that the visitor is valid; 0 for forever.
list OBJECT_CREATOR_LIST = [OBJECT_CREATOR];
key myCreator;


default
{
    state_entry()
    {
        myCreator = llList2Key(llGetObjectDetails(llGetKey(), OBJECT_CREATOR_LIST), 0);
        llListen(REGISTRATION_CHANNEL, "", "", "");
    }
    on_rez(integer start_param)
    {
        llResetScript();    // No harm; might save confusion
    }
    listen(integer channel, string name, key id, string message)
    {
        // Security (such as it is) : only listen to objects made by the same avatar as this one.
        if (myCreator != llList2Key(llGetObjectDetails(id, OBJECT_CREATOR_LIST), 0))
            return;
        llAddToLandPassList((key)message, ACCESS_DURATION);
        // Okay to add multiple times; land access list won't store duplicates
    }
}

_________________
Parcel Access Sensor

// License granted: Creative Common - Attribution (CC by)
// by Qie Niangao, 2008
//
// This script goes into an object set to a group that should have access 
// to the parcel where the "parcel access updater" script is running.
//
// Group members must be wearing their group tag to gain access initially.

integer REGISTRATION_CHANNEL = -1443885244;
float SENSOR_RANGE = 20.0;
float SENSOR_INTERVAL = 10.0;

list recentAvatarKeys = [];
integer NUM_RECENT = 20;
integer nextRecent = 0;

default
{
    state_entry()
    {
        for (; nextRecent < NUM_RECENT; nextRecent += 1)
            recentAvatarKeys = llListReplaceList(recentAvatarKeys, [NULL_KEY], nextRecent, nextRecent);
        nextRecent = 0;
        llSensorRepeat("", "", AGENT, SENSOR_RANGE, PI, SENSOR_INTERVAL);
    }
    on_rez(integer start_param)
    {
        llResetScript();    // No harm; might save confusion
    }
    sensor(integer num_detected)
    {
        integer thisDetected;
        for (thisDetected = 0; thisDetected < num_detected; thisDetected += 1)
        {
            key thisAvatar = llDetectedKey(thisDetected);
            if (-1 == llListFindList(recentAvatarKeys, [thisAvatar]))
            {
                if (llSameGroup(thisAvatar))
                    llRegionSay(REGISTRATION_CHANNEL, (string)thisAvatar);
                recentAvatarKeys = llListReplaceList(recentAvatarKeys, [thisAvatar], nextRecent, nextRecent);
                nextRecent = (nextRecent + 1) % NUM_RECENT;
            }
        }
    }
}

But I wonder if there's some way to actually grab group members directly, using any of the whiz-bang web stuff now. Or any other ideas?

One possibility is to maintain a member list independent of the SL construct, probably on an extenal webserver. Every time you induct a member to the group, add them to the database. Every time you eject someone, remove them from it. Then you can check with the webserver whether someone is on either list. They won't even need their tag active.

The downside, of course, is the parallel maintenance of the group lists. It means your tools have to be very accessible, and your group administrators have to stay on the ball and be diligent (fortunately if you implement it right, a screw up should be easy to fix). It may also not be very conducive to open-enrollment groups, though there are some ways around this: 1.) have a self-help system that DOES require the group tag, and adds to the external database list(s); 2.) use a custom client to regularly syncronize the external database to the list of group members (or do it by hand every once in a while, but that's a real pain, especially if the group(s) get large).

Of course, using an open-enrollment group for security purposes doesn't sound like a very likely setup, and ejecting someone from it wouldn't be very effective anyway. Heh.