How do you mark a package as being a "subsite package"? In the package's .info file? That would seem to be the "right" way to do it ...

What functionality is the RP performing? At first glance I'm not seeing why you can't just mount a package and dispatch to it, ala .LRN. Is it the setting of certain ad_conn values or something along those lines?

I don't worry about complexity in the RP much as long as it continues to be fast. We don't have to change it that often and not that many of us need to really understand how it works ...

In addition, does it set [ad_conn subsite_id] to the package id of the stand-in subsite package?

Currently a package adds itself to the "subsite_packages" table to identify as a subsite and then things like getting DefaultMaster and other things which you look for from the [ad_conn subsite] are just gotten from the package at it's mountpoint. The changes in the rp code are more changes to ad_conn to report subsite_id as whichever subsite package it encounters first walking up the tree.

Identifying via the .info file would be best of course but we could possibly just add a parameter SubsiteP=1 for those we wanted to be subsites.

I am not sure what you mean by "mount a package and dispatch to it, ala .LRN". How can you for example set the DefaultMaster starting from a non-subsite package?

Adding stuff like this to the info file and the APM package builder pages are very easy, I'd very much prefer we stick to the info file paradigm.

OK, you've confirmed that [ad_conn subsite_id] is one of the things that needs setting ...

.LRN sets the default master by a kludge, it assumes it is mounted under the main subsite and changes its default master parameter behind its back.

If we could define it as a subsite package it wouldn't have to do that, so you've just indentified something we could clean up once we have this facility. A small improvement but a very nice one, IMO.

So, yes, this is functionality you don't get by just visiting a mounted package that we don't call a "subsite". IIRC default master is driven off the [ad_conn subsite_id], ideally everything of this sort should be, if not at the moment, then someday.

APPROVE if it's spec'd in the .info file. If not, I need further convincing ...

Oh ... why do we need a subsite_packages table? If this is designated in the .info file then we can extract whether or not the package is a subsite when we mount just like the other "what kind of package am I?" attributes, and mark the node as a subsite node in the site map table, no? Add a column to that table, in other words...

Then any code which might be interested in whether or not a particular node is a subsite could tell by checking the site map table ...

This would make it possible to control the behavior on a per-instance basis, too ... now I'm getting a bit ambitious, but it would be slick if the portals package could be mounted as a subsite package (after the proper support's written) while also allowing it to function as a subsystem mated to .LRN.

Hmmm...probably should keep your proposal simple for now, though.

Not sure if this belongs here but in the past we had some schools who were interested to know if it is possible to have several dotlrn instances running on one openacs (Since all schools belong to one university) instance each with their own design. Would this be possible then?

Nima, no, it doesn't really relate. Not sure how hard it would be to make .LRN work if mounted more than once, Open Force made that decision early on and there are various bits of code that are hard-wired with the assumption that it's mounted once, and worse, mounted as /dotlrn.

On a related note. Would it make sense to move acs-subsite's group management stuff to a separate singleton package ala notifications so that these new "subsite" applications that have application groups don't have to add this to their packages?

Jeff, how are you handling this now?

Jeff handles it through a bunch of .vuh files.

The centralized services idea has floated before, but it would be a lot of work. Maybe someday ...

I'm thinking that for now we should just adopt Jeff's patch with the caveat (IMO) that we put the parameter in the .info file, that we think of the semantics as being "can be a subsite" while in reality currently the semantics will always be glued on via the subsite_packages table.

Later, if others have the need or desire to implement more flexible semantics, split off the membership services stuff from acs-subsite, etc they can do so. Wouldn't be that hard, for instance, to later augment the site node table with a "subsite" flag via upgrade scripts (though I kinda like doing that right off if it weren't difficult, problem being Jeff already has sites runnign with his existing code).

I wanted it to be a subsite from day one. But ... I know Open Force was on a very tight schedule. In a perfect world, that would've been when the user and group services stuff would've been broken out into a separate service package, with dotLRN than being an alternative to acs-subsite (and mountable multiple times).

Looks good. Jeff said on IRC that the new table isn't necessary.

APPROVE.

I've implemented this, in the form of a new "implements-subsite-p" global package attribute (i.e. same level as "singleton-p", not tied to version).

I've not implemented the portion of the TIP that explicitly calls the code to create an application group for the subsite-implementing package.

This is due to my having implemented this in conjuction with the new "EXTENDS" package dependency, which properly calls dependent apm callbacks when instantiating a package.

In other words, typically one would implement a subsite-like package by EXTENDing acs-subsite. Instantiate and mount will call the acs-subsite callbacks as well as your custom package, causing the application group (and anything else acs-subsite decides it needs now or in the future) to be created.

Coupled with the "inherit-templates-p" package attribute, and "EXTENDS", one can easily customize acs-subsite with custom enhancements, or build an entirely new UI while maintaining the necessary subsite semantics provided by acs-subsite.

Please comment. If there are no objections, I'll commit this upon approval of my implementation of package extensibility.