Dear Espen, sorry for late reply but it took long time for me to understand the issue.

In fact I did not know that it was possible (prior to r586) to specify a full path for the service location. And in fact looking on how other languages works not really acceptable. Indeed this lead to produce a rong status file name but I guess it is not the only issue which may happen.

I give a better look into the PHP support implementation yesterday and commited the result of this work in r586. So for now, the php file should be located in the same directory as the ZOO-Kernel itself or in sub-directory. In case a sub-directory then the service name will change automatically for being prefixed by the sub-directory name. For instance, if you place the orfeo toolbox services in a sub-directory named OTB (so located in your /cgi-bin/ directory where your ZOO-Kernel stand) then the service name will be OTB.ServiceName.

For instance, with the current PHP hello service, you can do the following to deploy your service:

mkdir /usr/lib/cgi-bin/php
co hello-php/cgi-env/* /usr/lib/cgi-bin/php

This will lead to the following service name php.HelloPHP.

With the restrictions implied by the new version of the PHP support this problem should be solved.

As you spoken about background service execution I also added a ZOO-API for the PHP language giving you access (amongst other things) to the updateStatus function which can be called to inform the ZOO-Kernel about the current step run by your service and its progress. Please, refer to this ​page for more informations on the PHP ZOO-API.

I hope you can confirm that the revision r586 solves your problem.

1. Library files are loaded from: [CWD]/[metapath]/[serviceProvider]
   
2. Stored execute response is written to: [tmpPath]/[serviceProvider]_[cpid].xml
   
3. A stored result file is written to: [tmpPath]/[serviceName]_[variable name]_[cpid].[file extension]
   
4. The main config file is read from: [CWD]/[metapath]/main.cfg
   
5. Service configs are read from: [CWD]/[metapath]/[serviceName].zcfg
   

CWD is the current working directory and serviceProvider is the library file specified in the ZCFG file. As a first step, I would suggest that we rename the stored execute response file by replacing serviceProvider by serviceName. Then, for example, in a call to the zoo-services/utils/status/longProcess service, the statusLocation would point to

[tmpPath]/longProcess_[cpid].xml

instead of

[tmpPath]/wps_status.zo_[cpid].xml

This is at any rate more informative when a library file contains several services. It would also have solved Espen's original problem, although only for PHP services prior to r586. To implement this file name change, we need to make the following source code modifications:

   // zoo_service_loader.c (r601), line 3272
   
   // map *r_inputs1 = getMap (s1->content, "ServiceProvider");
   map* r_inputs1 = createMap("ServiceName", s1->name); // replaces line above

    // service_internal.c (r601), line 2863

    printProcessResponse(m,request_inputs1,cpid,
		     // s,r_inputs->value,res,
			 s, s->name,res,  // replaces line above
			 request_inputs,
			 request_outputs);

The present use of the metapath parameter may be problematic. It appears that a client can supply the metapath in a KVP, although it is not a WPS parameter. This allows the user to navigate the server in a way that may be a security problem. Perhaps we should remove the metapath parameter in its present form. In its place, we could have a parameter that can only be specified in the main.cfg file, by the service provider, giving the relative path to a folder containing the library files. Alternatively, we could allow the serviceProvider parameter to give the absolute path to the library file.

Replying to landmark:

1. Library files are loaded from: [CWD]/[metapath]/[serviceProvider]
   
2. Stored execute response is written to: [tmpPath]/[serviceProvider]_[cpid].xml
   
3. A stored result file is written to: [tmpPath]/[serviceName]_[variable name]_[cpid].[file extension]
   
4. The main config file is read from: [CWD]/[metapath]/main.cfg
   
5. Service configs are read from: [CWD]/[metapath]/[serviceName].zcfg
   

CWD is the current working directory and serviceProvider is the library file specified in the ZCFG file. As a first step, I would suggest that we rename the stored execute response file by replacing serviceProvider by serviceName. Then, for example, in a call to the zoo-services/utils/status/longProcess service, the statusLocation would point to

[tmpPath]/longProcess_[cpid].xml

instead of

[tmpPath]/wps_status.zo_[cpid].xml

This is at any rate more informative when a library file contains several services.

I fully agree on this point. I feel that this should be implemented the way you specified here. Nevertheless, please make sure to read the next comments about the metapath usage.

It would also have solved Espen's original problem, although only for PHP services prior to r586. To implement this file name change, we need to make the following source code modifications:

   // zoo_service_loader.c (r601), line 3272
   
   // map *r_inputs1 = getMap (s1->content, "ServiceProvider");
   map* r_inputs1 = createMap("ServiceName", s1->name); // replaces line above

    // service_internal.c (r601), line 2863

    printProcessResponse(m,request_inputs1,cpid,
		     // s,r_inputs->value,res,
			 s, s->name,res,  // replaces line above
			 request_inputs,
			 request_outputs);

The present use of the metapath parameter may be problematic. It appears that a client can supply the metapath in a KVP, although it is not a WPS parameter. This allows the user to navigate the server in a way that may be a security problem. Perhaps we should remove the metapath parameter in its present form. In its place, we could have a parameter that can only be specified in the main.cfg file, by the service provider, giving the relative path to a folder containing the library files. Alternatively, we could allow the serviceProvider parameter to give the absolute path to the library file.

The metapath parameter is something historical in the ZOO-Project. It came from the fact that we would like to organize our services in a different way that simply putting all of them in the same directory, using different subdirectories for organizing services seam to be a good idea. So we introduced the metapath parameter for being able to handle such kind of organization. Nevertheless, this led us to have numerous of symlink for the main.cfg file, cause, as you specified earlier in your answer, the ZOO-Kernel expected to find also the main.cfg file located in the same directory. With our growing experience in deploying solutions, such as MapMint?, based on the ZOO-Project, we noticed that having multiple copies of the main.cfg was a problem. So we decided to have one and only one main.cfg file used. That is why we intorduced the concept of prefixed service identifier, so now the idea is to have the metapath hidden in the Service identifier. This way the metapath parameter should not be used anymore as a parameter but to define the prefix of the Service Identifier. This solved the issue about multiple location for the main.cfg file and make the deployment task much easier. So now, if you use the XXX.YYY.ZZZ Service Identifier, the metapath will be defined by the ZOO-Kernel as XXX/YYY at runtime (where XXX/YYY is the relative path).

Despite I feel unconfortable to completely remove the metapath, I feel confortable with the proposal to have the capability to define the library location in the main.cfg file or in a ZCFG directly. Rather than having a ZCFG, where you can set the full path to the library, I think it may be better to add a new parameter in the ZCFG file for defining it, for instance we may use a fullpath key at the root level which, if defined, can be used in place of the path created by the ZOO-Kernel as [CWD]/[metapath]. This way both the old way to load services and the new one can coexist.

I feel that this is a good solution, so we should add the capability to define fullpath by using a specific key in the ZCFG file and update the documentation on how to use it.

I think the idea of having a single main.cfg file, and the ability to select services using a metapath type mechanism, may be appropriate for many service providers. However, suppose that one wishes expose different sets of services to different user groups. If there is only one main.cfg file, then there will be only one tmpPath. This means that all stored result files will be accessible to all user groups. Also, the metapath mechanism, whether used in KVP form or as a prefixed service identifier, allows one user group to query and run protected services exposed to other user groups. I too think that a new fullpath configuration parameter, which if present overrides the metapath mechanism, may solve this issue.

In r605, the path for stored response files has been changed from [tmpPath]/[serviceProvider]_[cpid].xml to [tmpPath]/[serviceName]_[cpid].xml as suggested above. Support has been added for a new parameter, libPath, in the [main] block of the main.cfg configuration file. The libPath parameter is interpreted as the absolute path of the directory containing library files. If the libPath parameter is set, it will override the metapath parameter such that library files are loaded from [libPath]/[serviceProvider] instead of [CWD]/[metapath]/[serviceProvider].

However, the presence of the libPath parameter does not disable metapath completely because libPath is retrieved from the main.cfg file, whose path depends on metapath. To avoid the security issue this entails, it is now (r605) possible to disable metapath by compiling the Zoo kernel with the preprocessor directive IGNORE_METAPATH (the metapath will then be set to the empty string).

Note however, that the libPath and IGNORE_METAPATH options so far only work for C and PHP; the functions for loading libraries written in other languages (Java, Python etc.) should be modified correspondingly before the documentation is updated. Presently it appears that each zoo_[language]_support() function determines the path of the library file and is therefore required to obtain the metapath (and libPath) parameters. It is probably easier to determine the library file path in the calling function (loadServiceAndRun) and pass it as a parameter to zoo_[language]_support().

Note also that duplication of service configuration (ZCFG) files could be avoided if we added an include file mechanism. Suppose a service provider maintains a central repository of service files, e.g. /my/wps/directory/conf/. Suppose the provider also maintains several server addresses for different groups of services (with separate main.cfg files), e.g. http://my/server/wps/A and http://my/server/wps/B. Instead of having all ZCFG files for group A in one directory and all ZCFG files for group B in another directory, there could be, for each server address, a single configuration file containing include statements that import selected ZCFG files from the repository /my/wps/directory/conf/.