Forum OpenACS Improvement Proposals (TIPs): TIP #24: (Clarify/Resubmit) Maintaining the apm_service / apm_applicaiton distinction
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.
Certainly the user facing pages of general comments and notifications do get used.
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.
Also it is theoretically possible to mount search several times, e.g. with different parameter settings.
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'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:
- The separation of ui from functionality so that the underlying api can be presented to the user in several flexible ways.
- How re-usable code should be factored into packages that don't require the clients packages to depend on unnecessary stuff.
- How to seperate code which is considered core from non-core code.
- How to divide the administration responsibilities between different classes of user.
- 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.