RE: Curriculm

"Kevin O'Neill" <[email protected]> Mon, 31 Mar 2003 11:56:22 +1000
Newsgroups gmane.comp.belts.devel
Organization rocketred pty ltd
Message-ID <[email protected]>
On Mon, 31 Mar 2003 11:13:33 +1000, Ward, Nigel wrote:

> Just want to clarify what you are saying ...
> 
> In the current design, learning outcomes are not displayed within search
> results.  Instead, a link to "related outcomes" appears in the brief
> metadata for each search result.  The related learning outcomes for the
> learning object could be calculated when this link is clicked.

Correct.

> Are you suggesting that the cost of calculating matching learning
> outcomes when this link is clicked is too high, and therefore they
> should be pre-calculated for each learning object?

Correct. Lets say that we can match quickly, .1 of a second, to determine
if an outcome matches. Now lets say we have our low mark of 100 learning
outcomes. The time to determine a learning objects matching outcomes will
be approximately 10 seconds. This is in a one user scenario, the time will
increase in a non linear fashion as the number of concurrent users
increases.
 
> If pre-calculation is required, then I think calculation has too happen
> A) When a learning object (version) is loaded B) When the curriculum
> organiser is changed
> 
> (A) involves a calculation for just new learning objects (and versions).
> (B) involves a re-calculation for every learning object.  Presumably
> this could take a while if there are a large number of objects.

We have to have a (C) when the object is removed as we'll need to remove
the index information to stop the index growing forever.

The time to do (A) would be in line with my earlier calculations. It would
be scheduled on a lower priority thread to keep it from effecting
interactive operations.

(B) Would be in line with (A) * n. We have two approaches, 1) "rolling
changes" which will mean replace the entry for each LO as we process it
or 2) "blow it away and start again" meaning we remove the entries for every
LO before adding them back in. 1) would lead to slightly stale data
during the update period, 2) would be faster but LO that haven't been
processed will show no outcomes.


-k.

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://www.rocketred.com.au/blogs/kevin/




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en