DRAFT: Implement same-origin filter

[bevand10]

Given

• In some working scenarios, MOS servers are configured to emit main and reserve path traffic.
• In these circumstances, MOS messages, when collated by receiving MOS devices (that can have main and buddy servers defined), the main path and reserve path messages end up saved side-by-side in the same directory
• mosromgr does not work correctly when processing a directory of mixed main and reserve MOS messages received for the same running order

When mosromgr loads MOS messages from a directory

Then A filtering process should be applied to messages to skip those arriving via the buddy NCS server

AC/s

• That MOSROMGR will correctly order stories on a client configured with main and buddy NCS servers

BBC use of main and buddy Main and buddy NCS configurations are common across the BBC. See this recent example in Cardiff where Autoscript clients are configured with main and buddy server connections. The FIP servers in News are configured with main and buddy connections.

Developer notes Messages that emit from main and buddy servers feature a handy way to identify buddy messages.

A typical main message contains the following basic data:

<mos>
  <mosID>mosid.w1.bbc.mos</mosID>
  <ncsID>ncsid.w1.bbc.mos</ncsID>
  <roCreate>
  ...
  </roCreate>
</mos>

A typical buddy message contains the following basic data:

<mos>
  <mosID>mosid.w1.bbc.mos</mosID>
  <ncsID>mosid.salford.bbc.mos</ncsID>
  <roCreate>
  ...
  </roCreate>
</mos>

The tell-tail sign of a buddy message is a consistent difference between the domain_name values for used in the mosID vs ncsID elements in the message.

To