DescriptionThis CL generates mojom type descriptions for every Go .mojom file.
* Each Struct/Union/Enum/Interface will have a corresponding Mojom Type and Type Identifier.
* Each generated file will now expose a global Descriptor() function. This allows .mojom files to know about all the types relevant to their package. It is a map[string]UserDefinedType.
* Each Mojom Interface's ServiceRequest will now also expose Type() and Desc() on the "client-side", so that clients can know all the type metadata that they like about the service they are accessing.
* Each Mojom Interface also generates a ServiceDescription (service_describers.mojom) implementation. This allows Mojo server applications to additionally expose a ServiceDescriber implementation that directs interface name queries to the corresponding ServiceDescription.
Notes:
* The CL does not generate types for constants. The Go generator does not generate constants yet, anyway.
* A best attempt was made to preserve ordinals, but descriptions and such
are not included because the Python generator doesn't have those available.
The generation occurs as follows.
mojom_util_macros.tmpl:
- A helper that sets up the unique identifier for each mojom type.
This is essentially {package}_{typeName}__
This is used by the other jinja templates to attain consistent variable and
type key naming.
source.tmpl and mojom_reference_macros.tmpl:
- The String Identifiers are used (by reference), so they are best initialized
early on in the file. Some are exposed publicly (since other files may need them).
- Creates the init function where the mapping/descriptor is built.
It traverses each of the types defined by the user and registers those into
the map. If types are referenced from external files, these are found by
copying the mappings from the relevant mojom imports.
I think this is good since it saves a lot of runtime logic, and
the cost (larger maps during init) seems small.
- Writes the Descriptor() method to reveal the mapping.
mojom_type_macros.tmpl and struct/union/enum.tmpl:
- All of these call writeMojomType, which traverses the type and prints out
the corresponding MojomStruct.
- If there is a reference to an interface or a non-top-level struct/union/enum,
then a mojom_types.TypeTypeReference is used instead. As the spec describes,
this removes the possibility of generating a recursive value.
- The mojom_types.TypeTypeReference will use both Identifier and TypeKey as the
reference to the String Identifiers variables created earlier.
interface.tmpl:
- This generates the parameter (and possibly response) structs for each method.
- It also generates a mojom_types.MojomInterface that wraps up each MojomMethod.
- Lastly, it generates the ServiceDescription and Type() and Desc() methods for the ServiceRequest.
go/application/connection.go was also updated; the ServiceRequest now also has the Type() and Desc() methods on the interface.
Question:
- This CL allows writing a universal mojo client and a mojo proxy application. Should I write one or the other for Go? (Note that in a branch of mattr-google, this implementation is sufficient and was tested there.)
R=rudominer@chromium.org
Committed: https://chromium.googlesource.com/external/mojo/+/b30d89292737f11cf1b33e476212e8158c5e5d33
Patch Set 1 #
Total comments: 10
Patch Set 2 : Add Client and Server Hooks to the Type Description #Patch Set 3 : Replace Signature call with ServiceDescriptions #Patch Set 4 : Use unexported functions instead of variables #
Total comments: 17
Patch Set 5 : Templates Updated, Service Describer Implemented, Tests Added #
Total comments: 13
Patch Set 6 : Minor refactors for clarity #Patch Set 7 : GetIdentifier without a default #
Total comments: 6
Patch Set 8 : Update Comments and Enum Template+Tests #
Total comments: 4
Patch Set 9 : Wrap long lines #Patch Set 10 : Add a toggle that can turn off mojom type generation #
Total comments: 16
Patch Set 11 : Address Naming changes and Comment Updates #Messages
Total messages: 31 (3 generated)
|