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

Handling $refs which are HTTP URLs #34

Open
aktungmak opened this issue Jan 12, 2018 · 3 comments
Open

Handling $refs which are HTTP URLs #34

aktungmak opened this issue Jan 12, 2018 · 3 comments

Comments

@aktungmak
Copy link

Hi!

First, I am super glad you have written this library, it already does most of what I need to do, namely programatically generate structs from schema definitions like these:

https://redfish.dmtf.org/schemas/ComputerSystem.v1_5_0.json

As you can see, the a lot of the $refs are specified with URLs pointing to other locations. I can see that in generator.go:getTypeForField() you are parsing the string as a URL. What do you think about checking the url.Scheme field and making an HTTP request to resolve it?

I need to find a way to process all the redfish schemata so if you are interested on working on this with me let me know.

@aktungmak aktungmak changed the title Handling more complex schemas Handling $refs which are HTTP URLs Jan 12, 2018
@a-h
Copy link
Owner

a-h commented Jan 12, 2018

Thanks, I wrote it initially to do some grunt work for me at a client I was working with, and thought it might be handy for others. People have made really good contributions and improved it, which is great!

First thoughts are that downloading resources from the Web on demand should be disabled by default so that a misconfigured or malicious schema doesn't cause lots of data to be downloaded, but enabled by a parameter. Complex schemas could reference a lot of files, so downloading could be slow, a local cache might be handy, but not essential. It absolutely sounds like a useful change.

I don't have time to work on this at the moment, but I'd happily take a pull request. The work to support multiple files was contributed by @sqs (thanks again!) - I think your idea would build on that to resolve URLs.

@aktungmak
Copy link
Author

Yes, I completely agree - resolving remote resources should be an optional flag. I will fork and send you some PRs with any improvements I can make.

@kequeen
Copy link

kequeen commented Aug 4, 2023

is it still open ? where is you PR?

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

No branches or pull requests

3 participants