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

Document how to add a new kind and regenerate libraries #38

Open
R2wenD2 opened this Issue Oct 11, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@R2wenD2
Contributor

R2wenD2 commented Oct 11, 2017

No description provided.

@vbatts

This comment has been minimized.

Show comment
Hide comment
@vbatts

vbatts Oct 12, 2017

Contributor

regenerate like #46 does?

Contributor

vbatts commented Oct 12, 2017

regenerate like #46 does?

@R2wenD2

This comment has been minimized.

Show comment
Hide comment
@R2wenD2

R2wenD2 Oct 12, 2017

Contributor

Yeah, for backward compatible changes, #46 will handle it.

Contributor

R2wenD2 commented Oct 12, 2017

Yeah, for backward compatible changes, #46 will handle it.

@doomsbuster

This comment has been minimized.

Show comment
Hide comment
@doomsbuster

doomsbuster Jan 22, 2018

Is adding a new kind manual code change or will it be available through use of API's?

doomsbuster commented Jan 22, 2018

Is adding a new kind manual code change or will it be available through use of API's?

@furuholm

This comment has been minimized.

Show comment
Hide comment
@furuholm

furuholm Jan 22, 2018

Contributor

@doomsbuster: That needs to be implemented in code.

Contributor

furuholm commented Jan 22, 2018

@doomsbuster: That needs to be implemented in code.

@doomsbuster

This comment has been minimized.

Show comment
Hide comment
@doomsbuster

doomsbuster Jan 22, 2018

What would be the reason for that decision? I am wondering what the process to extend the Open API Spec with new kinds will look like. Enterprises with complex ecosystems will end up owning their own versions of Grafeas and introducing new types?

doomsbuster commented Jan 22, 2018

What would be the reason for that decision? I am wondering what the process to extend the Open API Spec with new kinds will look like. Enterprises with complex ecosystems will end up owning their own versions of Grafeas and introducing new types?

@furuholm

This comment has been minimized.

Show comment
Hide comment
@furuholm

furuholm Jan 22, 2018

Contributor

I think this is a question for @R2wenD2 to answer as I was not part of the founding team.

I do see that there could be a need to add your own types in some situations. That being said: I personally think that one of the key value propositions for Grafeas is having standardized types as this allows different tools (both internal and 3:d party) to work together.

Contributor

furuholm commented Jan 22, 2018

I think this is a question for @R2wenD2 to answer as I was not part of the founding team.

I do see that there could be a need to add your own types in some situations. That being said: I personally think that one of the key value propositions for Grafeas is having standardized types as this allows different tools (both internal and 3:d party) to work together.

@doomsbuster

This comment has been minimized.

Show comment
Hide comment
@doomsbuster

doomsbuster Jan 22, 2018

That being said: I personally think that one of the key value propositions for Grafeas is having standardized types as this allows different tools (both internal and 3:d party) to work together.

Agreed

But I also do see a need to extend the vocabulary in several cases. Is it a possibility to extend vocabulary through use of plugins or providers?

doomsbuster commented Jan 22, 2018

That being said: I personally think that one of the key value propositions for Grafeas is having standardized types as this allows different tools (both internal and 3:d party) to work together.

Agreed

But I also do see a need to extend the vocabulary in several cases. Is it a possibility to extend vocabulary through use of plugins or providers?

@R2wenD2

This comment has been minimized.

Show comment
Hide comment
@R2wenD2

R2wenD2 Jan 22, 2018

Contributor

We have kinds defined in the schema so that tools can understand what to expect (as @furuholm mentions above), as well as the ability to query backing data stores efficiently using filters as defined in fields of the kind.

We haven't yet added a proto.Any for easy extensiblity because we wanted to understand what Kinds people would want to add and understand what's common so we can support more.

Contributor

R2wenD2 commented Jan 22, 2018

We have kinds defined in the schema so that tools can understand what to expect (as @furuholm mentions above), as well as the ability to query backing data stores efficiently using filters as defined in fields of the kind.

We haven't yet added a proto.Any for easy extensiblity because we wanted to understand what Kinds people would want to add and understand what's common so we can support more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment