I have several clients who are interested in using OpenACS for
multiple, related sites.  I know that it's possible (using nsvhr) to
have one copy of AOLServer host multiple virtual hosts.  My question
is whether I can (or would even want to) have multiple OpenACS sites
share a single database.

In most cases, I can see where this would be a bad idea; if there
isn't any overlap among the users, administrators, or page design,
then sharing an OpenACS instance wouldn't be of much help.

But I have another client where the whole point of the system is to
have multiple domains that share a list of users.  That is, the same
user and groups will apply to www.abc.org, www.def.org, and
www.ghi.org -- but the contents and design of the three sites will be
different.  Each site will be able to choose which applications it
wants to use, which I'll simply mount on an appropriate URL.

(In case you think that I'm totally out of my mind for wanting this,
consider that abc.org is an umbrella organization that includes
def.org and ghi.org.  And there are common members to def.org and
ghi.org that we'll want to query from the umbrella organization, in
addition to the individual organizations.)

Does anyone have any good suggestions for doing this sort of thing?  I
imagine that virtual hosts with AOLServer is the right way to go, but
perhaps rewriting the URLs (with AOLServer or Apache's mod_rewrite) is
the right thing to do.

But I have another client where the whole point of the system is to have multiple domains that share a list of users. That is, the same user and groups will apply to www.abc.org, www.def.org, and www.ghi.org -- but the contents and design of the three sites will be different.

I am working on exactly this problem with Greenpeace International, which is made more complex by the fact that we're talking about countries, which means the various subsites are to be presented in different languages. We're basing our work on OpenACS 4.5.

The basic mechanism which is available is acs-subsite. You can mount as many subsites under the main subsite as you wish, and then - as Simon suggests - use the site-node mapping feature to point your various domain names to the appropriate subsite.

You can change the look and feel of each mounted acs-subsite instance by changing the "default master" parameter to a subsite-specific master. This master will let you wrap custom headers and footers, and if you use a table for the page, custom column elements. For instance you could have a leftmost column nav widget that's customized for each subsite, with content from the OpenACS 4.5 packages put in the right column.

And of course each master can define its own CSS stylesheet.

This alone gives you considerable power to change the look and feel for each subsite.

In the case of Greenpeace, this isn't quite sufficient so we're providing a mechanism to allow the mapping of arbitrary custom templates to arbitrary package pages. I have some ideas for generalizing this in the future for use in the standard toolkit, but frankly I think 90% of folks needs can be met by the process I describe above using subsite-specific default master templates.

Currently all users in OpenACS 4.5 have access to all subsites. There's a special "membership" group in acs-subsite that allows the segregation of folks by subsite, but this isn't interwoven into the various packages at this point in time. However, it sounds like you want everyone to have access to each subsite. You can control access further by use of permissions ...

Not quite... the host-node map maps something like

www.my-domain.com

to a subsite (or URL) such as

/my-domain... i.e. it maps to www.real-domain.com/my-domain

Therefore you can have different URLs point to the same AOLServer instance, but when request hit the site, the host-node map directs them to the appropriate subsite based on the URL they requested.

so, you could have three subsites mounted as

msite.com/
    /sub-1
    /sub-2
    /sub-3

with sub-one.com mapping to sub-1
sub-two.com mapping to sub-2
and
sub-three mapping to sub-3

then if someone went to www.sub-two.com they'd actually end up at your subsite i.e. /sub-1

Cheers
Simon

So when are we going to see an OpenACS 4 LJ article? wink, wink, nudge.

How about an introduction to AOLServer in the September issue, followed by several articles on OpenACS in the October through December issues?

I actually would have started on OpenACS previously, but Apache 2.0 and the LJ 100th issue forced my hand a bit. But don't worry; OpenACS will get treatment equal to what I did for J2EE and Zope! (The article -- and book, I hope -- comparing the environemnts will come soon afterwards...)

Reuven, check out GrandEx. It was built by aD, and makes good use of subsites.

Subsites might turn out to be the killer application for openACS. Being able to provide a complete web presence for a parent organisation while allowing each subsidiary to customise its own look and feel is not as unique a requirement as one might think.

As PhilG might put it, it becomes a lot easier to build purposeful communities around particular subsidiary/product/brand/department/region .....

With subsites, portals, groups and host-node-mapping (dotLRN anyone?), one can build some really powerful websites!