Forum OpenACS Q&A: Subsites with separate domain names - issues
zebra.com +- apple.com (subsite) (root) | -forums | -blog | -etp |- banana.com (subsite) | -forums, blog, etc |- carrot.com (subsite) -blog, photoalbum, etcSites aren't accessed by the root domain name, although technically the user could get to the apple.com content by hittind zebra.com/apple, the expectation is that they're using the apple.com domain name.
Ok, so far so good. I can mount subsites, set up the host-node map, and get some packages working. However, I'm seeing some issues that make OpenACS less subsite-friendly than I'd like. (Some of this is also documented in bug #1447.) Here's a list. If there's an obvious great solution to some of these, I'd love to hear it :)
- Notifications - notifications cannot be mounted in more than one place - doing so causes forums/ to error out (due to multiple nodes being returned). However, each subsite needs to have notifications mounted, to allow apple.com/blog and carrot.com/forums visitors to use notifications. (See also bug #1453, where lars-blogger mounts notifications and causes forums to break on server reboot.) Additionally, it would be nice if notifications used the subsite domain instead of the main site domain when sending emails.
- Context bar - The context bar by default goes back up the zebra.com main site, although the zebra.com content isn't even accessible to a user visiting through apple.com. So my context bar looks like "Zebra" (with a link to slash) | Apple (which is actually /apple, but that resolves to apple.com, so it's ok) | Forums, for example. Preferred behavior would be to not show parts of the site map that are closer to the trunk than the point that apple.com points to. I need to try the suggestion in this thread, where Malte asks about something similar - Tom's suggestion may be just what I need.
- General Comments - several packages need general comments. Fortunately, one can mount general comments in multiple places without (at least so far) any problem. However, GC is not subsite aware, and shows every comment on every subsite. As I am aiming for the illusion of 3 separate instances, this is undesirable.
- Each subsite creates its own "Subsite Parties" group. (And Subsite Members, Subsite Administrators.) From admin/permissions, there's no indication which of the three "Subsite Parties" corresponds to the subsite that contains the package I'm actually modifying. Suggestion: Change generic names to include the subsite name. (This can be done after the fact with the groups UI, but it might be preferable to do it automatically - *if* the subsite name is known when the groups are set up.)
- Admin links and documentation - an /acs-admin link is offered to a main site admin visiting a subsite, although apple.com/acs-admin doesn't work. (Subsite admins seem to be offered only an /admin link, which works fine.) Should things like /acs-admin, /api-doc, and /doc work from within any subsite/domain by default?
In order ...
1. You need to customize the context bar yourself and I think this makes sense. Because as a default I think treating an OpenACS site-with-subsites as something of an integrated whole is correct. We might want to parameterize the toolkit so you can install it in a "each subsite is its own world" mode.
2. Making general comments subsite aware should be easy, and it is possible Daveb has done so in his improved version which is in contrib. This will eventually replace the existing general comments package but he needs to fix the gawdawful attachments package rewrite first.
3. Notifications is probably fairly easy to fix.
4. Yes, it would be good to customize subsite group names automatically.
5. Links to global admin doc and similar directories should probably be generated with a fully rooted URL rather than short-handed the way they are.
I don't have time to work on any of these issues myself at the moment, but am available to answer questions by e-mail...
Are you just concerned about being able to efficiently share machine resources and want to run within a single AOLserver instance? If so AOLserver's virtual server facility would do what you want, allowing you to define resource pools for virtual servers that can be shared or separate etc.
True, but it isn't all that far off from being able to do it, either! :)
I haven't played with AOLserver 4 yet - if this turns out to be too much headache, I could certainly go that route. It seems like that would still be higher resource usage, no? Wouldn't each instance have its own loaded procs? (Caveat: I know nothing about AOLserver 4.)
I got the context bar working this afternoon. Tom's suggestion in the thread linked above was spot on.
Things I can see:
- User has the same password across all sites and does not have to register more than once.
- You can aggregate statistics across all sites.
- You use one tablespace.
Things I can see that are not in favour:
- If a subsite becomes to large it is not easily possible to transfer it to it's own server.
- Not sure about the seperate access statistics and how they would work.
- Customizing the functionality on one subsite is not possible (easily)
This will occur because it is not possible to have a tool kit that fills all the needs, and because it not easy to know how to modify a module so we could still sync it with the CVS tree.
The templateing system is a good way to allow modification of a module look but what if we like to modify a module behavior ?
For example, in my case I like to create a mechanism to control which user maybe register to a group. My first thinking will be to modify /acs-subsite/register but in doing so I will not be able to sync it with the main CVS tree...
Here are some notes from a brainstorm I had with Branimir recently:
It's something worth thinking more about, and then once we do it, we do it right.