**Issue a)
I'm thinking about the programatic creation of a subsite for each group along with unique subsite-associated admin and user groups, and then automated creation and mounting of package instances under the subsite. These are all actions that are currently performed manually by a site-wide administrator using the site-map and groups UIs.

**Issue b)
Along with subsite creation and package mounting, I'll need to utilize a payment gateway that can handle subscription-based and use-based collection.

I haven't (yet) located examples, discussions, or API doc to tell me how to handle the programming of issue a), so I'm beginning to trace through the site-map code to figure this out. I don't know quite where to start with issue b).

Has anyone already addressed either or both of these issues? Can anyone gently point me toward resources that might help me?

Randy

If anyone is going to work on this, please let me help. I have decided to use the subsite feature and I already had to change the datamodel.

Ben of OpenForce suggested that his folks had solved some problems they found, but he didn't elaborate. One I found annoying is that when you login/register you see the main site info.

One thing definitely needed is the ability to place users into a specific subsite group. The ability to create subsite types is also a great organizing idea. This needs to have a tcl or pl api so other packages can create new subsite types easily.

dotLRN community or club is general enough to cater needs of non-educational groups, similar to Randy's req. above issues a) and b).

There is already a project created for this dotWRK , not much active right now, but that should be active soon given high interest level. You can also check out dotLRN demo, linked from http://openacs.org/projects/dotlrn

Now, I am searching for an acceptable method to programatically delete a subsite. The subsite may have other  applications and subsites mounted beneath it. In addition, there is at least one side-effect of creating a subsite that also has to be addressed, and that is removal of the "Parties" application group and its relations that are associated with the subsite.

I see the process going something like this:
1) identify all site nodes subordinate to the subsite
2) for each of the subordinate nodes, unmount and delete
3) unmount the subsite itself
4) delete the "Parties" application group
5) delete the subsite
6) pray... (actually this should be step 0

First, am I missing anything?

Second, how might I go about performing step 1?

Randy

The hardest part right now is #1. Currently there is no way to delete a package that has already been mounted. You can unmount it, but the code necessary to remove the objects that package has created does not exist.

We do need a way to delete individual package instances and the content they contain. I see this happening rarely on a production site, but for someone who wants to test or try out a package it would be very useful.

I see two options, either a service contract or a magically named tcl proc for each package. A package developer would be required to provide a tcl proc that would accept a package_id and correctly remove the objects that belong to it. Some people have mentioned that comprehensive use of on delete cascade in the OpenACS data model would also accomplish this.

I agree. That is definitely a case where removing an object should be handled better. But besides acs_objects which nearly all packages will have, each package has it's own internal data that also must be removed correctly. It is this data that must be removed by the package itself.