Full custom component support for each renderer

[jacobsimionato]

Full custom component support for each renderer

Supporting custom components in a renderer has a few moving parts, many of which are not implemented right now. We should have a way for developers to see how custom components are wired up end-to-end on at least one platform. It requires the following:

Specification describes update catalog negotiation mechanism

We are moving the clientUICapabilities message to a metadata parameter, as described in A2UI UI Extension JSON format Working Doc. We need to properly document this in the specification.

The gist is:

• Server advertises multiple catalogs and can advertise support for inline catalogs
• Client specifies one catalog to use and specifies it in metadata with every message.
• The client can specify a well-known catalog by URI or an inline catalog, if the server supports that
• Styles will be defined in the catalog definition document

Renderer has Catalog and CatalogItem registration API

An API to specify components, their URI, API and rendering logic. This is already done in the Flutter codebase (see CatalogItem, Catalog, and example usage in Travel catalog, example item), partially in the Angular codebase, but not web.

Renderer advertises which catalog to use

The renderer needs to specify which renderer to use in the message metadata.

Agent demo can advertise support for and handle a custom catalog

Agent implements the custom component handling e.g. by advertising support for a custom catalog and successfully rendering from it.