Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial specification for plugin support #126

Closed
wants to merge 2 commits into from

Conversation

smallsamantha
Copy link
Member

@smallsamantha smallsamantha commented Jul 12, 2024

This PR is a work in progress, open questions need to be addressed before full review.

  • How should a Plugin indicate it supports Generated SDKs?
  • How should a Plugin indicate it is verified/managed?
  • How should a Plugin [and Module] represent its license?
  • Should a filter on deprecated Plugins be provided on ListPlugins?
  • Should a filter on Generated SDK support be provided on ListPlugins?
  • Should an Update endpoint be provided?
  • How should revision be validated?
  • How should semver version be validated?
  • How should digest be validated?
  • Should it be specified that Modules/Plugins share a namespace (so names across both types must be unique per owner)?
  • How should individual, language-specific Plugin configuration be represented?

Copy link

github-actions bot commented Jul 12, 2024

The latest Buf updates on your PR.

NameStatus
build✅ passed
lint✅ passed
format✅ passed
breaking✅ passed

option go_package = "buf.build/gen/go/bufbuild/registry/protocolbuffers/go/buf/registry/plugin/v1";

// Operate on Plugins.
service PluginService {
Copy link
Member

@mfridman mfridman Jul 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we're planning to bring in the ResolveService, but it'd be nice if we stubbed out a single RPC to resolve Generated SDK version. Something like

rpc ResolveGeneratedSDKVersion
rpc ResolveSDKVersion

Basically folding all the Get{Go,Swift,Maven,NPM,...}Version into a single RPC. You could argue that this fits nicely with the "PluginService".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally there's also an RPC to get a registry-specific package ID. Could be the same RPC.

Copy link
Contributor

@saquibmian saquibmian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drive by

google.protobuf.Timestamp update_time = 3 [(buf.validate.field).required = true];
// The name of the Plugin.
//
// Unique within a given User or Organization.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this imply that each version/revision of the plugin has a different name?

Comment on lines +126 to +129
// Semver-formatted release version of the Plugin.
string version = 3;
// The revision of the Plugin. This represents the BSR image version of the Plugin.
uint32 revision = 4;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be under Name? Why would I want to specify these if I have the plugin ID?

@mfridman
Copy link
Member

Partially superseded by #132.

TBD on code generation plugins, but this is the first milestone towards Check plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants