I would like to hear some more details on how this would be done. For example, what happens to the user and admin pages in general comments? Do you create a second package called general-comments-app which has those pages or do you provide .tcl/.adp includes for packages which use general comments to provide their own admin pages?

Certainly the user facing pages of general comments and notifications do get used.

Notifications, general comments at least need to be fixed so they can be mounted once per subsite.

In cleaning up general comments I had fixed it so that the comments were keyed to a general comments package_id so that I could keep the comments seperated by the subsite under which it is mounted. Now that I think of it, storing the subsite that owns the comment would be fine. Then we just need to be able to mount a notifications or general comments instance under each subsite.

As Jeff says it might be best to make a datamodel/tcl-api package and a seperate user interface package.

Ok, so there seems to be some terminology confusion here. I think there are at least two important issues to consider:

1) Which packages do we offer for installation for an admin. IMHO general-comments should not be offered even though it has user visible pages. It simply does not make sense stand-alone. Related to this is whether it makes sense for an admin to mount a package. Again, I don't think it ever makes sense for an admin to mount general-comments. Services tend to be auto-mounted and general-comments already auto-mounts.

2) Should a package show up as a link in user navigation (and as a tab in Lars's new subsite UI), i.e. does it have a user UI (as opposed to only an admin UI) that it makes sense for the user to navigate to? This may be the case for general-comments, although I'm not sure.

Both those two properties should I think be attributes of a package. My thinking was that apm_application would indicate 1). For 2) we would need a new attribute.

I think a full solution to this issue may be defered to after 5.0.

I think it makes sense for a service package to provide reusable forms and other parts as includable adp templates. These shouldn't be full user pages and should reside in package-key/lib/

I'm not very clear on what we are trying to acheive with the separation of services from applications. There seems to be several issues involved:

1. The separation of ui from functionality so that the underlying api can be presented to the user in several flexible ways.
2. How re-usable code should be factored into packages that don't require the clients packages to depend on unnecessary stuff.
3. How to seperate code which is considered core from non-core code.
4. How to divide the administration responsibilities between different classes of user.
5. Whether a package is a singleton package or can be mounted multiple times.

It's not clear to me what, in the context of these issues, is implied by being a service or an application.

Specifically I want to address the issue of ui separation but to avoid hijacking this TIP I'll post it as a separate one.