There are flyspray requests (#FS1881, FS#1587) for a Guard Zone (GZ) for watching AIS
targets to see if they are getting too close to a position regardless of whether they are on a collision
course or even moving towards the position. Currently the AIS
code handles all the processing of information regarding AIS targets and displays the alerts if deemed needed. The concept
of a Guard Zone requires drawing the zone on the chart and then watching to see if any AIS target enters this zone.
The OCPN_DRAW (OD) plugin can draw the zone and check to see if any given lat/lon is within the zone. This is currently being done for the Boundary alarms using the Watchdog plugin. The Watchdog plugin communicates with OD through the OCPN messaging process. This seems to work well for this type of interaction where a single
lat/lon is checked to see if it is either inside or outside a particular or any boundary.
If the GZ were to be drawn by OD then either the AIS code would need to query OD for each AIS target to ascertain whether it was inside a GZ, or would need to broadcast a message for each target so that others could do the check. At best, if the AIS code does the query, there would be one message for each target sent to OD and a subsequent response message saying the lat/lon is inside or not the GZ Boundary. So for each target there would be two synchronous messages. The more structured case would be a broadcast message for each AIS target, the Watchdog plugin would pick this up and query the OD plugin to see if an alert is needed. This would result in 5 synchronous messages for every AIS target. As there appears to be certain locations that have large numbers of targets (hence the work on scaling the targets) this would result in a large number of messages per timer event in the AIS code.
As mentioned the current
messaging in OCPN is using a synchronous model and there is a high probability that that the time taken to process the messages could exceed the timer events
causing them. This would either cause the timer to be ignored or double events
to be processed.
Is there a need to re-examine the messaging within OCPN to allow for large numbers of messages that, at times, may take longer to process than the time available.
At the moment there are only a few messages being sent around the system, so broadcasting is acceptable. Does this need to change to allow directed messages as well?
Should mainline OCPN code use messages that are sent to specific plugins or should the mainline remain unaware of the plugins? The reverse, i.e. plugins sending messages to the mainline, also needs to be answered.
Do we need to start documenting the messages being sent and the responses to these? Do we need a more structured approach to the message content or should it be left to the parties directly involved in the communications