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
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
