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

Collapse
1: TIP #24: (Clarify/Resubmit) Maintaining the apm_service / apm_applicaiton distinction
Posted by Peter Marklund on 10/07/03 10:36 AM
The following packages are currently apm_applications but are candidates for becoming apm_services:

search
bulk-mail
general-comments
notifications
user-profile
authorize-gateway
cronjob
monitoring
robot-detection
sample-gateway

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.

Collapse
2: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Jeff Davis on 10/07/03 11:01 AM
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.

Collapse
3: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Lars Pind on 10/07/03 01:58 PM
Yes, notifications, general-comments, bulk-mail are special cases that we need to figure out what to do with.
Collapse
4: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Dave Bauer on 10/07/03 03:06 PM
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.

Collapse
5: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 4)
Posted by Tilmann Singer on 10/07/03 03:16 PM
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.

Collapse
6: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Peter Marklund on 10/07/03 05:07 PM
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.

Collapse
7: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 6)
Posted by Tilmann Singer on 10/12/03 11:30 PM
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.
Collapse
8: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Dave Bauer on 10/15/03 06:56 PM
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/
Collapse
9: Re: TIP #24: Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Dave Bauer on 10/29/03 07:41 PM
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.
Collapse
10: Re: TIP #24: (Clarify/Resubmit) Maintaining the apm_service / apm_applicaiton distinction (response to 1)
Posted by Lee Denison on 12/03/03 07:55 PM

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.