tile module architecture

[khklau]

The handler hooks in Apache2 are generally a terrible framework because a module has deal with a callback heavy control flow and needs to use either ap_set_module_config or your own method to persist state and associate it to the right virtual host, connection and request.

The tile module architecture should try hide as much of the hook nastiness as possible. Other goals for the architecture include:

• per worker resources should be initialised on Apache2 start and re-initialised on restart
• configuration should be loaded on Apache2 start and reloaded on Apache2 reload; since configuration of a resource might change, this also means resources need to be re-iitialised
• make it easy to persist state and automatically associate it to the right virtual host, connection and request
• decouple front end the slippy request handling from the back end renderd tile serving or cache fetching
• support a middle step in the pipeline to support filtering & rewrite type processing
• observers for all events in the front, middle and back ends

[khklau]

On second thoughts it's probably better to make the tile module architecture very simple and put the complexity of an asynchronous tile server into the renderd replacement.

[khklau]

The required processing would roughly be:

1. parse the request
2. evaluate the request:
   2.1 straight forward for layer description
   2.2 straight forward for statistics query
   2.3 for a tile serve request:
   2.3.1 calculate which meta tile the requested tile belongs to
   2.3.2 if the meta tile exists on disk, return a file handle to it
   2.3.3 else
   2.3.3.1 send a render request to renderd
   2.3.3.2 start polling for the reply
   2.3.3.2.1 if ModTileRequestTimeout is exceeded return a RETRY-AFTER header and SERVICE UNAVAILABLE response code
   2.3.3.2.2 if not response received yet, sleep and poll again
   2.3.3.2.3 else process the response
   2.3.3.2.3.1 return a DECLINE on error
   2.3.3.2.3.2 return a file handle to the metatile on success
3. respond to the client:
   3.1 with appropriate code on error
   3.2 with a meta tile written to the client connection on a returned file handle

[khklau]

So the tile module would have simple blocking until timeout architecture.

The complexity of retrying will need to be handled by the client side map library like Leaflet or Open Layers provided 503 unavailable code is returned with a retry-after header.