CGI and DestroyStack property

[Tariel Gogoberidze]

On Thu, 27 Apr 2006 19:23:51 -0700, Richard Gaskin  wrote:

> The stay-resident option will bring you speed, but since the only thing
> a given user does with other user's stacks is read them I see no 
> penalty
> to reading them all, collecting what you need, and report that back to
> the user.
>
> This will work with just about any configuration, and if later you
> migrate to FastCGI or other stay-resident scheme you'll also enjoy a
> performance boost, but anything less needn't shut you down in the 
> meantime.

>   Richard Gaskin


You have a point, but here is the situation. Each quiz would have 
50-100 students at a time (so stacks would have to be created and saved 
on the fly) and  it would be several quizzes per year, again new users, 
so eventually it would be thousands of stacks to read from. Scalability 
problem on top of potential speed problem.

Additionally summary data returned must immediately include the data of 
users who already finished current quiz.

I can keep "history" data summarized in stack and dump incoming current 
quiz data to just one file in delimited format . During the quiz CGI 
would read from both stack (history data) and file (current quiz data), 
merge and send back to student who finished the quiz.

After entire quiz is done, instructor can send "quiz_done" command, CGI 
would read file, merge data to stack, delete file and save the stack.

That's probably easiest way to implement this particular task and the 
only problem I have with this solution is that it looks more like 
"workaround"  :)

Besides, I'm experimenting with MC CGI instead of "regular" database 
option with the longer term goal of adding  it as additional tool to 
our toolset. For this "write to stack" conflicts must be solved and the 
good news is that it seems to be possible on OS X

best regards
Tariel