Crane

Before implementing this ourselves, it's worth looking to see if there's anything here we can use: https://github.com/vpavlin/registry-face

I thought about a couple of viewing options for the repositories served by crane and here are the 2 options that seem feasible given the requirement and the given timeframe.

1. json view - This will be a similar json view like what we have for images and tags.
Serving URI will http://host:port/v1/repositories and the format of the json will be -

{'repo_registry_id1': {'images': [image_id1, image_id2, ...], 'tags': [tag1, tag2, ...], 'protected': false},
 'repo_registry_id2': {'images': [image_id1, image_id2, ...], 'tags': [tag1, tag2, ...], 'protected': false}, 
 ...
}

2. HTML view - Instead of json, we can use Flask's 'render_template' to render it in HTML instead, although I am not really sure whether we have a strong usecase for HTML view instead of json.
In any case, it is achievable and I tried it with a couple of small examples. Information in the result will be pretty much the same as above, just in the html format.

Perhaps we want to support both?

Thoughts?

The json representation looks fine. I do think both a json representation and an HTML representation be supported.

I propose that the web handler that serves this page inspect the "Accept" HTTP header. This will allow the client to be in control and adhere to the HTTP standards about how to specify that. If "Accept" is set to "application/json" then the json should be returned, otherwise it should return an HTML view. All other values of "Accept", or if "Accept" is missing should return the HTML view. This way machines can specify "Accept" and get what they want, but the default view is human readable.

I propose that the CSS library PatternFly be used to provide some formatting assistance for the HTML. A simple, single page layout is probably the way to go. It will improve readability, be visually consistent with a lot of other Red Hat stuff, and it should abstract cross-browser compatability problems easily enough.

Normally I would say that we should do a mockup before implementing a visual design, but in this case I think trying to render the json data using PatternFly in a reasonable way without a mockup is good enough. I can help answer questions in working with PatternFly or blocker issues that come up. I haven't worked with it specifically but it is built on top of bootstrap which I've done a lot of work with.

Also when forming HTML always make sure to validate it using the W3C HTML validator.

To represent the json data with PatternFly you'll need to write a template that loops over the json data and builds the right tags that PatternFly will know how to present visually. This is all about having the right HTML entity contain the right class label. We can talk through this some if its not straightforward from the PatternFly docs. Figuring out how to get Flask to render that simpler once you know the HTML it needs to produce.