Forum OpenACS Development: Re: Re: Current best practises: Dynamic Attributes, Package Linking, Callbacks
Excuse me if this is off topic but I don't have much experience with dotLRN and not even
had time to play with the new project manager package.
In the clustermanagers system we decided to create projects just as subsites because we saw them
more like project-rooms where you can add/remove members, link any package you want (etp, forum, file-storage,
chat, log hours, events, calendar, etc) and even change the look and feel per project. The possible combinations
are amazing and you just need to create the rigth callbacks procedures in each package to link them all.
For that reason I really like the idea of creating a subsite for each project. However I remember
a discussion about "spaces" and "subsites" in the dotWRK project by Lars:
(Sub)sites and spaces
Brainstorming about OpenACS site-map/navigation/structure with Branimir ...
We discussed the distinction between a (sub)site and a "space". A subsite is something that has a specific
appearance, it has its own login page, one "your account", etc ... A space is a place where specific people go
to work on specific things -- a project, a special-interest group, etc. We currently use the 'subsite'
application for this purpose, too, but logically, I don't think there should be a "Your Account" page,
for example, per space. Just one per site.
The reason we came to this is, we were playing around with the host-node map to map http://foo.test.com to a the
subsite at http://test.com/foo. This broke a bunch of things, such as the site-wide admin link, which will now
require to be a fully qualified URL that goes to http://test.com/acs-admin/, not just the current /acs-admin.
(There are other things broken about host-node-map; for example, it cuts off parts of the URL, so if you
say http://foo.test.com/foo2 it does a redirect to http://foo.test.com2 - go figure!)
Anyway, we want to do multiple sites on one OpenACS instance, where those sites are completely isolated from
each other, completely different design, no admins on the one site should ever have to know that the other
sites even exist. So when you go to "Your Workspace", it's on the (sub)site.
But in this scenario, I wonder if you even want to have the user database be shared. Just because I have
an account on one site that shouldn't mean I have an account on the other sites.
Also, I'm not sure there's any point in mounting a site inside of another site. If the sites are completely
isolated, what would the implications be?
Things that would remain site-wide:
- software installation/upgrade
- internationalization/localization
- package manager, and other developer features
Things that are currently site-wide but would belong to the "site":
- users
- authentication
So it seems like OpenACS' current subsite construct is half-way between "space" and "site".
What do people currently use subsites for? To what extent can we make changes to this (it's pretty core...)?
Does this still make sense? Some advance in this direction was made?
Thinking about scalability, currently we have about 1000 users, 50 subsites, an average of four project
per subsite and a heavy use of permissions, in a single instance of oacs (in a not dedicated Athlon
2600 machine), and performance has not yet been a problem.
About the /portlet/o/$object_id functionality I don't really know what are you talking about.
Hope it helps.
