In an general sense, I suppose it would be possible to set up a persistent hash where the key is a unique ID and the value is the parameters. When generating the email, the parameters would be stripped off the URL, and stored in the hash against a new unique key. The key would then be added to the URL. When the CGI is run, it would look up the values against the key.

That's pretty much what I envisaged, but why not have two hashes going both ways. The keys of the other hash are the params and the value is the unique id. Then when you generate the email look to see if the id for this combination of params already exists, and if it doesn't generate one and insert a record in both hashes

My objection to this is it's not possible to tell when a given hash entry can be safely deleted.

I think that under my scheme, as you're reusing the same id for the same combination of parameters you won't need to delete entries from the hashes.

I may be misunderstanding the problem tho'.

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

Reusing the hash keys is a good idea, but where one of the parameters is, for instance, an key referring to an entry in a database table, which is constantly incremented, then new hash entries will be created on an ongoing basis.

-- Michael Snell
-- michael@snell.com

You do not say how many options there are for each parameter. If there are only a small number of responses then the call could be replaced by a one or two character sequence. A number of these could be concatenated into a simple string.

Caillte,

http://www.server.com/cgi-bin/script/script.pl?Mode=view&Area=12345&Su
+bArea=12345
[download]

would be a fairly genernal example.

regards,

-- Michael Snell
-- michael@snell.com

Hi snellm,

I think this is fun. What you actually need to do, is to represent your data into just the bits that you need, and hack these bits into 8-bits chunks (aka bytes), and transform these bytes into usable characters. This sounds like UUencoding. However, UUencoding uses too many characters.

CPAN sayz: Convert:UU
I would suggest that you take that module, and remorph it a little bit to use only a range of usable characters. Wait, I'm doing a perl -MCPAN -e shell, install Convert::UU.

Hmm.. I see this package just uses pack("u",$string) internally. Well, the search continues. It is obvious that I haven't used pack before!

Let's play a little bit. Maybe you want 16 different modes, and 2 16 bit integers for your Area cq Subarea. That adds up to 36 bits (2**4=16). If we use A..Za..z0..9 *and* '%', '-' we have 64 possibilities, or 6 bit. Than we can cram everything in 6 characters.

The encoder must pack the stuff:

sub encode{
 my $mode = shift;
 my $area = shift;
 my $subarea = shift;
 my $str;
 my $bitstr=unpack("b4",pack("v",$mode)).
     unpack("b16",pack("v",$area)).
     unpack("b16",pack("v",$subarea));
 for (0..5){
     my $val=unpack('c',pack('b6',substr($bitstr,$_*6,6)));
     if ($val<10){
         $str.=pack('c',$val+48);
     }elsif ($val<36){
         $str.=pack('c',$val+65-10);
     }elsif ($val<62){
         $str.=pack('c',$val+97-36);
     }elsif ($val == 63){
         $str.=pack('c',37);
     }elsif ($val == 64){
         $str.=pack('c',45);
     }
 }
 $str;
}

sub decode{
    my $str = shift;
 my $bitstr;
    for (split //, $str){
     my $item = unpack('c', $_);
  for ($item){
            $val = 64, last if $item == 45;
            $val = 63, last if $item == 37;
            $val = $item-97+36, last if $item >= 97;
            $val = $item-65+10, last if $item >= 65;
            $val = $item-48, last if $item >= 48;
  }
        $bitstr .= unpack("b6",pack("v",$val)); 
    }
 $mode = unpack('c',pack('b4',substr( $bitstr,0,4)));
 $area = unpack('v',pack('b16',substr( $bitstr,4,16)));
 $subarea = unpack('v',pack('b16',substr( $bitstr,20,16)));
 ($mode, $area, $subarea);
}

$encoded=encode(15,13,13);
$decoded=join ', ', decode( $encoded );

print "Encoded: $encoded\nDecoded array: $decoded\n";
[download]

Some reverse coding for the decoder, but I'm too lazy for that. Is this what you want to do?

Disclaimer: This is my first use of pack, so I'm not sure I'm doing the right thing, let alone the efficient thing. Please correct me!

Cheers,

Jeroen
"We are not alone"(FZ)

Update: Made the decode sub as well. Tested it. Discovered some differences between running at linux and at mac at home, so used 'v' for packing stuff.

Now I've moved this code into a module, for generalized use. You can find it here.

http://www.server.com/cgi-bin/script/script.pl?vx12345x12345

And in the program:

use Env qw(QUERY_STRING);
(my ($mode, $area, $b_area ) = split 'x', $QUERY_STRING;
$mode = 'view' if($mode eq 'v');
[download]

I'm a little confused at this point. I think davorg's idea is a pretty good one, as it makes it possible to pass around the session ID and reconstruct the data on the server side. I suppose you could also construct the session-ID using a two-way algorithm rather than MD5 (i.e. use a method you can decode with the proper key ... the RSA algorithm isn't patented any more =)

What do you want to consider a "safe" deletion? After a certain time? (store an expiration date in the database for each hash) When a certain percentage of (unique) respondents have used the session ID? (Ditto, you update the dB for each unique respondent).

Philosophy can be made out of anything. Or less -- Jerry A. Fodor