fix(pubsublite): rename publish.Metadata to pscompat.MessageMetadata

[tmdiep]

Since publish.Metadata now also applies to message ids, it was renamed to MessageMetadata. It is duplicated in the internal/wire and pscompat packages.

Follow up for #3662.

See also the Java equivalent googleapis/java-pubsublite#482.

[tmdiep]

@tbpg @codyoss @hongalex
FYI this is a minor API change - rename of the publish subpackage to types. It contains utils for parsing some Pub/Sub Lite specific info that we had to encode into string fields of pubsub types.

[tbpg]

A types package is generally discouraged in Go. Here is a great explanation from rakyll: https://rakyll.org/style-packages/#organize-by-responsibility.

If we need this in a separate package (I think we do?), consider the name message? Then we have message.Metadata and message.ParseMetadata.

[tmdiep]

@tbpg Thanks for your offline suggestion about having the Parse function just return the fields, and removing the subpackage entirely. Discussed with other folks and we generally prefer parity and consistency with the other languages. This feature was requested by a user for the Java lib and we expect a small, but non-trivial number of users to need it.

So I renamed the package and struct to message.Metadata.

There is another option - move the struct to internal/wire, add a type alias and Parse function to pscompat. But feels a little clunky and since it's a seldom used util, I prefer to keep it out of the main packages.

[tbpg]

Thanks for your offline suggestion about having the Parse function just return the fields, and removing the subpackage entirely. Discussed with other folks and we generally prefer parity and consistency with the other languages. This feature was requested by a user for the Java lib and we expect a small, but non-trivial number of users to need it.

I don't understand how not having the type or extra package makes the Go library not have parity with the other languages. What is the benefit of a type over returning the fields directly? The GoDoc will document exactly what is returned. If it's in another package, it will be harder to find, there is another package for users to have to import, etc. Ideally, the function would show up right next to the thing users will need to use it with.

[tmdiep]

@tbpg @manuelmenzella-google

I don't understand how not having the type or extra package makes the Go library not have parity with the other languages. What is the benefit of a type over returning the fields directly?

We wanted a struct mostly for consistency with the other languages. Extensibility if we encode more fields (e.g. we may need to add an epoch to the partition number for repartitioning).

If it's in another package, it will be harder to find, there is another package for users to have to import, etc. Ideally, the function would show up right next to the thing users will need to use it with.

Good point. Maybe pscompat.MessageMetadata then? It will have to be a type alias for the actual struct in internal/wire, unfortunately, due to import cyclic dependencies.

The pubsublite package kind of works too, since it is Lite-specific, but it's not used with anything in that package.

[tmdiep]

@tbpg @codyoss

There is now a pscompat.MessageMetadata struct (which is actually an alias due to cyclic dependencies) and pscompat.ParseMessageMetadata function.

LMK if you have any concerns from an API perspective. Thanks!

[tbpg]

Thanks! Looks good to me.

I left one question about duplicating vs. aliasing. Can see it both ways.