Here's a couple of questions that we'd like to find answers to before we commence development of the datamodel for Curriculum (which will be the first step and start pretty soon, we hope).
The presupposition is that Curriculum will show up in OpenACS 4.7 / dotLRN 1.1 ...
- Should the development work be conducted on the head of the trunk or on the tip of the oacs-4-6 branch?
- Should we demand that people use PG 7.3 and thereby be able to take advantage of the increased default parameter limit of 32 params (compared to 16 in 7.2) and the new maximum attribute length of 64 characters (compared to 32 in 7.2)?
- Do we want to base this package on the Content Repository or on plain acs objects, i.e., content_type vs object_type? We're planning on having two custom types, "curriculum" and "element", and though we are not storing the actual learning content in this package nor in the CR (rather, Curriculum points to content anywhere) we might benefit from CR features such as search, etc, for element and curriculum descriptions for example ... OTOH acs objects may very well suffice in this case.
- What privileges/roles do we need? The basic "read", "admin", etc., or something more granular like "curriculum-create", etc?
- We should probably prepend the Curriculum types and table names with a short prefix since names such as "curriculum_curriculums" tend to become rather long. How about "cu_"?
- Anything else technical concerning the datamodel that I'm forgetting?
I'm sure that more questions will arise soon, especially when it comes to Oracle.
Oh, what comes to mind right about now is; what is the preferred way to split up (Oracle) package create scripts? Should package definitions go in one script and the package bodies go in another?
/Ola
