dan: right, creating department admins is not difficult, but it will require some work on the admin UI and the dm. since sloan doesn't use department except to organize classes, this issue never really came up. I'm not the authorrity on dotlrn groups/relsegs, so I'm guessing a little, but I don't think that there are deep design issues that prevent this from being implimented.
peter: "Isnt this the designated setting?" sorta. dotlrn reflects sloan's organizational structure in some ways, such as in this case. they don't have a need for many departments, so the functionality for real-world use of many departments is not there yet.
The comments in the code mean that one should not create more than one main dotlrn instance _per openacs instance_. parts of the code assume that there is one and only one main (or top-level) dotlrn instance per openacs instance. on one physical server you can run many openacs/dotlrn instances with no problems. examples would be having one box running a dev oacs/dotlrn server and a production oacs/dotlrn server. so this requirement is not terribly limiting.
i don't know exactly how sloan is using departments, so i'll let them comment on that part.
"Will there be multiple dotLRN instances for different academic programms?"
it depends on how the administration of the different academic programs is structured. if they share common administration, then one dotlrn instance with a dept for each program makes sense. if their admin is completly seperate, then seperate dotlrn/oacs installations makes more sense with the current code.
"Is there always only one department responsible for a subject?"
yes. this is one example of why adding real-world dept functionality to the current dotlrn system is more complicated than it seems both from a code and a UI standpoint.
