Forum OpenACS Development: Re: Current best practises: Dynamic Attributes, Package Linking, Callbacks

I talked to Timo a little bit about it and we came up with the idea, as we "only" need a forum and a folder for each project, to use one instance of project manager, forums and filestorage and to create folders / forums whenever a new project is created. As the forum and the filestorage folder would be generated through the project manager we might be able to have the context_id set to the project_id of the project we just created.

This has the benefit of reducing the of site node entries and does not take with it the "overhead" of acs-subsites. Additionally it does not even need callbacks as the "associated" forums_id and file-storage-folder ID can be stored within project manager.

If we then have a functionality like /o/$object_id working, then we could arbitrarily add objects to a package and when you call the view page e.g. for a project it would check which objects are linked to it and call the /portlet/o/$object_id functionality that returns the default include for the display of the object.

I guess it is a good time we meet in Madrid and I hope we can sit down over a couple of glasses of wine and think a little bit more as I assume this might be of general interest, especially as the goal is not that much different from what .LRN tries to achieve.

I just want to add my five cents about projects and subsites, based in my experience at Competitiveness.
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.