It would be nice if Zoo incoming request header values can be passed on in the data gathering requests.

By example, if an incoming request's header contains: SecurityToken?=ASDGARSGFABDAGRSGW$!$WGW, then, all requests to downstream WFS services would have the value of the SecurityToken? added to the header of the outgoing request.

Now, obviously, a specific prefix for the variables would be required because we do no need nor want all header variables to be passed on so, something like ZooSecurityToken?, or ZooWhateverMyVariableNameIs? would be valid.

With this, someone that uses a security via tokens can secure Zoo.

This idea is to cicumvent the fact Zoo does not allow impersonation to take place so that, incoming credentials are passed thru to outgoing requests.

Hi I was using this simple collection of 14 points and the voronoi diagram (displayed in QGIS) has got the far right hand 2 points in a single cell. attached is the gml file and the results.

Hi,

We used zooproject in a clustered mode. So we have a database backend to share ongoing informations of running services between 2 ZOO-Kernel instances. When the load on the cluster increases, some requests fails due to databases errors :

ERROR 1: ERROR: duplicate key value violates unique constraint "services_osid_key" DÉTAIL : Key (osid)=(1593003150) already exists. ERROR 1: ERROR: insert or update on table "responses" violates foreign key constraint "responses_uuid_fkey" DÉTAIL : Key (uuid)=(519e1ea2-b481-11ea-917c-005056b8dc20) is not present in table "services".

• The osid value calculated by the kernel is not unique

The osid is calculated by the script zoo-project/zoo-kernel/zoo_service_loader.c (line 830) : sprintf (tmpBuff, "%i", (cpid + ((int) tp.tv_sec + (int) tp.tv_usec)));

• In some cases, the PID variation is cancelled by the timestamp variation