Forum OpenACS Development: Re: How to handle dotlrn-specific changes in core?

Collapse
Posted by Torben Brosten on
Hi Malte,

I don't know. My understanding of the core is quite limited.  What would scale well?

The tcl gets compiled during the first execution. Looking at the new tcl benchmarks[1], I would think an extra if/else or switch would not be significant.

An 'if else' statement would work for cases where behavior needs to be consistent site-wide, and only 2 choices are available. Multiple conditions might suggest using a 'switch' statement, right? And since the default would be openacs, dotLRN procs could be called at their current locations without disruptive efforts of having to copy or move huge chucks of code around.

Maybe proc attributes should be used for cases when the choice does not have to be exclusive site-wide, with the default openacs behavior assumed when the attribute is not present. Since the core handles permissions, maybe declaring certain group-names/types as reserved would work as well.

Regarding where to store the parameters/flags, perhaps a cache-able table of parameter-value pairs loaded once on startup exists?

I'd imagine that guidelines for when and how to roll dotLRN behavior into the core will develop quickly as specific issues (like this thread) are brought forth and TIPped.

1. http://wiki.tcl.tk/tcl%20Benchmarks