Schemas/Journal: Carrier-related events

[Athanasius]

It is proposed that the following Fleet Carrier related events be allowed in the Journal schema:

• CarrierDecommission
• CarrierCancelDecommission
• CarrierJumpRequest
• CarrierJumpCancelled
• CarrierDockingPermission
• CarrierNameChanged

Please discuss any objections, caveats or possible problems with this.

[Tkael]

CarrierDecommission: Strip the ScrapRefund property.

Everything else looks good to me.

Other carrier events we might consider:

• CarrierShipPack and CarrierModulePack could provide data about available shipyard and outfitting services on a carrier.
• CarrierTradeOrder perhaps for publishing data about changes to player markets without requiring someone else to dock at the carrier first.
• CarrierStats for the Name, DockingAccess, AllowNotorious, and (perhaps) ShipPacks and ModulePacks properties.

[Tkael]

I believe that many of these events can be triggered from orders given when the player isn't docked so our standard data augmentation may not apply here. That said, we should consider what carrier-specific data augments we might want for the events we do eventually approve.

[Athanasius]

As per current policy these events should not be added to the journal schema, but instead to either a schema each, or possibly a common fleetcarrier schema. I really am in favour of a schema each, that way we don't have to tie ourselves in knots with making the applicable schema as strict as possible whilst not disallowing valid things.

[kenneaal]

These events would be useful for FCMS, as the data it retrieves from CAPI relies on valid OAuth tokens, which have a maximum lifetime of 28 days from the last time the carrier's owner actually logged in to FCMS. Although it is capable of using market and docking events to track some changes, certain variables are not available through the events currently broadcast on EDDN, such as the vanity name, or changes to docking permissions.