I've been reading through the a2a.proto and have some questions and suggestions.

Questions:

• What is the current support level for the protos?
• Will we see a reference implementation? I've been unable to find any implementations, only code generated from the protos.

Suggestion: Avoid using multi-segment variables in google.api.http annotations.

While I appreciate the intention of being able to define both a gRPC and REST APIs in one shot, I find the usage of multi-segment variable captures in the google.api.http (REST) annotations (ex: /v1/{name=tasks/*/pushNotificationConfigs/*}) to have produced some rather unattractive compound field values (ex: name with a value tasks/my-task-id/pushNotificationConfigs/12345). These will not only require that gRPC service implementations perform additional parsing that could have been handled by generated code, but it also requires that gRPC clients be aware of the REST api path structure when forming their requests. I am of the opinion that these annotations should be replaced with annotations that better leverage the capabilities of those implementing the google.api.http rule specifications.

Example of problematic proto

For example, the rpc for GetTaskPushNotificationConfig:

led to a GetTaskPushNotificationConfigRequest message with a field name requiring a value of something like tasks/my-task-id/pushNotificationConfigs/12345.

Code using a gRPC client would need to form the message:

client.GetTaskPushNotificationConfig(ctx, &GetTaskPushNotificationConfigRequest{
  Name: fmt.Sprintf("tasks/%s/pushNotificationConfigs/%d", myTaskID, pushID),
})

Further, our server would be required to parse tasks/my-task-id/pushNotificationConfigs/12345. Who knows what kind of implications there might be for handling malformed requests.

Suggested

Do the following, instead:

  rpc GetTaskPushNotificationConfig(GetTaskPushNotificationConfigRequest)
      returns (TaskPushNotificationConfig) {
    option (google.api.http) = {
      get: "/v1/tasks/{id}/pushNotificationConfigs/{push_id}"
    };
    option (google.api.method_signature) = "id,push_id";
  }

message GetTaskPushNotificationConfigRequest {
  string id = 1;
  int64 push_id = 2;
}

Client RPC code would look like:

client.GetTaskPushNotificationConfig(ctx, &GetTaskPushNotificationConfigRequest{
  ID: myTaskID,
  PushID: pushID
})

And the service implementation wouldn't be need to do any special processing.