Enhancements to messages defined in BrowserTypes

[Roaders]

Enhancement Request

Use Case:

I am a developer implementing a Desktop Agent Proxy that will use the proposed messaging protocol to communicate with a Desktop Agent. The types defined in BrowserTypes are very helpful but there are things that can be done to make things easier.

• Have a union type of all messages called FDC3Message (name is just an example. I am not good at naming things! feel free to suggest a different name)
• The FDC3Message union type should be composed of 2 other union types RequestMessage and ResponseMessage
• Have a RequestMessageBase and a ResponseMessageBase. All response messages should have a source: AppIdentifier and request / response uuid in the meta object for example (I am not sure how practical this is but some commanality between messages would be great)
• Have a type predicate defined for each message type:

  export function isAddContextListenerRequest(value: any): value is AddContextListenerRequest{
  return (value as AddContextListenerRequest).type === "addContextListenerRequest"; 
  }

  This isn't necessarily the desired implementation - we could probably use some of the logic from the Convert class to do a better check that it is in fact a valid message. The important bit is the type predicate return type.

We have already implemeted a lot of type predicates and union types but I am not sure how useful it would be to contribute these as I understand that the BrowserTypes are generated by magic so that magic should probably also generate the predicates and union types.

[kriswest]

@Roaders There exist AppRequestMessage, AgentResponseMessage and AgentEvent message schemas and types. See:

• https://github.com/finos/FDC3/blob/d94171986ccca791d570439ecfc366e4f9665ca0/src/api/BrowserTypes.ts#L86-L101
• https://github.com/finos/FDC3/blob/d94171986ccca791d570439ecfc366e4f9665ca0/src/api/BrowserTypes.ts#L172-L188
• https://github.com/finos/FDC3/blob/d94171986ccca791d570439ecfc366e4f9665ca0/src/api/BrowserTypes.ts#L233-L247

The types are structurally compatible with all messages derived from them so you can use them to write generalized TypeScript code in your implementation. However, as we generate the TypeScript code from the schemas, the type definitions of specific message types don't formally extend these types - but as TypeScript uses structural compatibility rather than than more traditional declarative typing that should not matter (other than it feeling a little odd to those of us that grew up with OO languages).

Given the number of messages, we should try to avoid creating a manual maintenance situation wherever possible (lest we incur the wrath of future generations of FDC3 maintainers). However, I believe it could/should be possible to come up with a way to generate some of your above suggestions by post processing the BrowserTypes file.

Type detection does seem like something the Convert class could be doing...