Forum OpenACS Development: Difference between Service and Application Package

1: Difference between Service and Application Package

Posted by Peter Alberer on 03/18/02 10:26 PM

I have some questions about package types (and maybe the request processor).

What is the main difference between a Service and an Application Package ?
Is there any difference between a Service and an Application Package as far as files in the /tcl directory of a module are concerned ?
Are procs that are defined in a /somemodule/tcl/somemodule-procs.tcl file available to all other packages ?
Or are they just available if they are defined in a "service" package ?
If this is the case can i redefine a package to be a "service" ?

In general i made some rather weird experiences calling procs between packages (defined as apps). Sometimes a proc is available and a few page reloads later it cannot be found. Could problems like these be caused by procs that are defined only in one thread and not in another ?

Hopefully my problems do not sound too stupid :)

Many TIA

2: Response to Difference between Service and Application Package (response to 1)

Posted by John Mileham on 03/18/02 10:53 PM

Hi Peter,

Apps and services are essentially the same, and can be treated the same at a nuts and bolts level. The difference is how they are used. Rarely, if ever, is a service mounted to the site map. It is there to define data model and API for other services and applications to draw upon. Applications can do the same, but they are also intended to be mountable. Application/service hybrids (i.e. apps that provide a bunch of API or data model intended to be generally useful) should be tagged as applications, or split into multiple packages.

I can't account for the problems sharing procedures between apps that you described beyond a caution that very strange things can happen when using a combination of watching files in the APM admin interface and restarting AOLServer. If, for example, you have a working procedure in a Tcl library and you accidentally insert a bug that causes a parse error in the Tcl library (like a missing close brace), reloading the file through the APM will not cause the procedure to disappear (the old procedure didn't get overloaded, so why should it?)... it will remain in its old state. You won't even know (unless you've got an open tail -f on the log file) that the reload failed. If you were to start wondering why your changes don't seem to get sourced, and resort to restarting aolserver, you'd discover that the proc disappears entirely. This can generate some real head-scratchers on occasion, and has tripped me up more times than it should have given the fact that I already know about the problem.

3: Response to Difference between Service and Application Package (response to 1)

Posted by Don Baccus on 03/18/02 11:44 PM

John points out the intended difference between an "application" and a "service" but it turns out that this doesn't provide the necessary granularity. This was true of certain aD packages and will become more true as time goes on.

We really need to differentiate between mountable and non-mountable packages (and refuse to mount non-mountable ones that have no pages), and so-called "service" and "application" packages. Application packages will always be mountable but service packages may or may not.

The problem is that service packages frequently provide a small set of (typically) administration pages. There's nothing wrong with them doing this and for this reason such packages need to be mountable.

As far as the problem with procs being loaded or not depending on where you call it from, I've never seen that. John's pointed out some possible "gotchas" ...

4: Response to Difference between Service and Application Package (response to 1)

Posted by John Mileham on 03/19/02 01:49 AM

Don,

It would make a lot of sense to me to put any generalized admin UI for a non-mountable service into /packages/package-key/www/admin and use some special case logic to publish it to /acs-admin/package-key (even though my natural inclination is toward /admin, the fact that it's owned by subsite makes that incorrect).

This would parallel the hack that pulls docs out of /packages/package-key/www/doc and publishes them to /doc/package-key. This could be applied to both singleton applications (as singleton packages have no scoping) and unmountable services, and allow us to put a list of admin-able packages on the acs-admin page.

I'm not sure that this would meet everybody's needs, though... does anybody have a justifiable reason to mount a service other than for admin UI?

If this works for everybody, it could even be used to mount the APM UI, if the UI provided in /acs-admin/apm and /acs-admin/users were seperated out into independent "service" packages in and of themselves. Then acs-admin would actually be just a simple singleton package publishing all of the available singleton or unmountable package admin directories within itself.

BTW, It's always struck me as strange that /doc worked the way it did... I would have thought that /packages/package-key/doc would have been the right thing to publish (and if i'm not mistaken, some version of the acs4 documentation implied that that was the right place to put documentation). I would be up for a move of documentation out of the package www directory and putting admin outside of it as well, but i suggested the above to make as few waves as possible.

Thoughts?

5: Response to Difference between Service and Application Package (response to 1)

Posted by John Mileham on 03/19/02 02:02 AM

I just realized that mounting admin UI for singleton packages in this way wouldn't be correct, because though singleton packages have no scope in particular, you might not want them to be administered by site-wide-admins... for instance, a singleton package may be mounted under a subsite (for its exclusive use) and the subsite admin may wish to have control over it. That said, it would still work for services in a truly unmountable-service world.

6: Response to Difference between Service and Application Package (response to 1)

Posted by Peter Alberer on 03/20/02 12:44 PM

Now i have found out what caused my problems:

Suppose there are 2 packages: package1 and package2. Proc p1 is defined in package1-procs.tcl and proc p2 is defined in package2-procs.tcl. Proc p2 is calling p1 at some point.

The problem is this: Every package-proc.tcl file is reloaded again after some time. Sometimes package1 is loaded first, sometimes package2. If package2 is loaded first it does not know Proc p1 as package1 has not been loaded.

How can i be sure that package1 is sourced before package2 ? Would it help to define a dependency in the package manager ?

7: Response to Difference between Service and Application Package (response to 1)

Posted by Don Baccus on 03/20/02 07:33 PM

Yes, dependencies are the trick to get things loaded in the right order.

But having said that, the procs don't need to be "known" until they're called, and all the libraries will be loaded before they're called, so it shouldn't be a problem, unless ... you have top-level (non-proc) code in a proc library file that's being executed.

That's not the right place for such code. Code that's executed at start-up time should be placed in an "*-init.tcl" file rather than the "*-proc.tcl" file. All the library files are sourced before the init files are sourced, so putting stuff in an init file guarantees that all the procs you need exist.
.