Forum .LRN Q&A: How to run multiple parallel .LRN instances

Hi everybody,
has someone experience with running multiple instances of .LRN on a single machine but with the same user base. As far as I can see the different schools at our university prefer to have their own designs thus a single installation won't work.

Do I have to copy an install.xml file in the root directory of openacs with multiple application elements:

My experience has been to set up different AOL server instances running on different ports, and point each instance to the same database (in the <instance>.tcl file).

If the only reason to have multiple instances is to have different designs, there is a way of doing this, but it is a bit of a hack and will affect performance because it involves effectively turning off the template caching.

It does work, though, and you can apply a different master templates to each community/subgroup and the way I implemented it, you can choose whether child subgroups inherit their parent's template or not.

If you want more details, let me know - although I hope I am wrong and there is another way :)

I have a similar problem: I've got different departments that want different logos and color schemes for their departmental identity as well as an institute which would like to have their own instance altogether. So, I'd like to learn how others have solved these two problems, too. Thanks!

Install.xml is using during site installation to determine which packages to install initially. It's not touched after that. If you want several different "sites" that share a common user database, use subsites. Create a new subsite for each different department, and use the features of acs-templating (modifying the default templates in each subsite directory) to give them unique appearances. If you want to run two different, isolated instances on the same computer, you need a separate OpenACS instance (ie, directory tree, config.tcl, database) for each. You can then give each one a unique IP, or have them share an IP and use different ports, and direct incoming traffic with any of several different virtual hosting schemes.

I have not done this with dotLRN, but I have had several ACS sites (ACS Classic, the old stuff) using the same data. It has worked just fine. So I would say that yes, you could do this, but my guess is that using subsites is a better way to achieve what you are after. I can think of a lot of unexpected user experiences you would get from running two dotLRN sites off of the same data, that are not a problem with our older sites.

Although it would be possible (as far as I know) to run multiple sites that use the same data, it still wouldn't really do what you want, because all of a student's courses would be visible in each one (meaning that in each site, most of the courses would look "wrong"). And the more they looked like different sites, the more you would have users who were surprised that a customization they made on one site showed up on the others.

What is really needed is the ability to set theme by class/community, but that feature doesn't currently exist.

Nima - you are right in stating the problems that exist should subsites work, however, I don't think they can in any event.

Janine - I missed the obvious! Different instances would present the same communities with different presentation, so that would not be much use unless you started a very messy filtering process - I don't think I'll go there!!
You mention themes, but I guess you mean designs as opposed to the actual .LRN themes, as they only go a little way to providing a custom look.

If people are interested in our solution, I'll gladly provide details. It's not ideal for 2 reasons:

- It involves a change to template_tag in the templating handler, which seems fairly core stuff
- The templating cache has to be refreshed constantly because I could not find another way around a problem where the master template would be cached from page to page, even if it had changed. Obviously this change is detremental to performance, although I'm not certain to what degree.

The second issue is probably resolvable if someone with more experience looked at what was going on - in the end I got it to work and we are living with the performance hit.
The first issue is only significant if this was a feature people wanted in core .LRN, so I guess it would be down to whether this was put forward as a TIP.

Would it be possible with your implementation to install multiple dotLRN instances with different look but same user base? If yes. I really would like to learn how you did that. But as I said (and I think Janine meant the same) it makes only sense if courses/communities are presented seperately on different instances while the user still has an aggregated view on all his/her subscriptions under My Space.

What our solution does, is allow one instance of .LRN to be customised so that each community or subgroup can have it's own specific master-template.
That mean each community or subgroup can have it's own look that extends beyond the community portal and into the package pages (e.g. forums). The user portal would still use the master-template specified by the ACS main site.

So the question that arises is this:

If a user is a member of 2 communities, each with a different master-template, does it matter that when they go to Community A, the forums-portlet and forums pages look different to those in Community B?
The answer depends on several factors: how different are the designs? Are people expecting a different look? Would it surprise them that the fishing club's pages look different to the chess club's pages?

One thing to consider is the use of closed communities and limited users.
If you wanted to host seperate communities/groups with a discreet set of users, you could set them up as limited users (can't see other communities, no personal portal if member of one community only).
The other thing to consider is design. You could make the design for one community very, very different to that for another; but in practise you will be constrained by the structure of the .LRN portals, portlets and pages in general. So although the package pages could look very different, I don't think they would be so different as to make it confusing for users to understand.

you are right. Regardless of the performance issue of your solution the result you achieved is what I am looking for. The problem is that while all schools want to share a similar site structure they want to distinguish themselves with different look (different header logo, slightly different color sheme and portlet design). While pages look similar in their structure that user knows that he changed from business school content to computer science to law school...which I think is even a helpful orientation as long as the site structure and the overall design is not to different.