Forum OpenACS Improvement Proposals (TIPs): TIP #24: (Clarify/Resubmit) Maintaining the apm_service / apm_applicaiton distinction

The following packages are currently apm_applications but are candidates for becoming apm_services:


The way I've understood it, the rule for something being an application is if something makes sense to pick for a non-developer administrator to install, i.e. whether it's an end user application.

I propose that we turn these packages into apm_services.

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.

Yes, notifications, general-comments, bulk-mail are special cases that we need to figure out what to do with.
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.

I don't see why search would be a service instead of an application. It serves its purpose only when it is mounted and has user visible pages. openfts-driver and intermedia-driver that it uses should be services, but I guess they already are.

Also it is theoretically possible to mount search several times, e.g. with different parameter settings.

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.

Another thing regarding the search package - I don't think it should be part of the core at all (initial-install-p is set t in the .info file). At least not as long as there is no oracle support with intermedia-driver.
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 think we need to address the problem of notifications, general-comments, etc user interfaces on subsites, especially host-based subsites before we can make this change.

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.