add API for Image Files providers

[feloy]

Signed-off-by: Philippe Martin [email protected]

What does this PR do?

Adds an API for extensions to registrer as an Image Files provider.

Inspiration from spec and Node implementation of Image builder.

What issues does this PR fix or reference?

Part of #7801

[benoitf]

it's still unclear to me:

• if the namespace is correct (like shouldn't be part of the provider namespace)
• the metadata argument as we already provide the object (like why it's not part of the object given)
• if the pattern is register where we provide everything or create (returning an object with helper methods)

[feloy]

it's still unclear to me:

• if the namespace is correct (like shouldn't be part of the provider namespace)
• the metadata argument as we already provide the object (like why it's not part of the object given)
• if the pattern is register where we provide everything or create (returning an object with helper methods)

I wanted to keep the same pattern as for the image checker API

[benoitf]

@feloy but why it can't go to the provider namespace vs having to declare a new imageFiles namespace ?

[feloy]

@feloy but why it can't go to the provider namespace vs having to declare a new imageFiles namespace ?

I mean that if we move the function to the provider namespace, there will be a specific namespace for the image checker providers imageChecker, but for the image files providers, the function will be in the more generic provider. Also, if we change from register pattern to create, there will be 2 different patterns to register image files vs checkers providers.

I would prefer to be consistent between both providers. Or do you think we should, eventually, move the function from the imageChecker namespace to the providers one?

[benoitf]

probably imageChecker should be moved as well

[benoitf]

there will be 2 different patterns to register image files vs checkers providers.

we already have 2 patterns for contributions, as they're bringing different kind of value.

create pattern and register pattern

if we have common 'helper functions' in all the implementations, probably it's more following the 'create' pattern

createImageFileProvider(...) : ImageFileProvider
vs
registerImageFileProvider(...): Disposable

[feloy]

there will be 2 different patterns to register image files vs checkers providers.

we already have 2 patterns for contributions, as they're bringing different kind of value.

create pattern and register pattern

if we have common 'helper functions' in all the implementations, probably it's more following the 'create' pattern

createImageFileProvider(...) : ImageFileProvider vs registerImageFileProvider(...): Disposable

OK, I'll have a try using the create pattern.

If I understand correctly, the ImageFileProvider would provide a registerFiles?

If so, would it be preferable to have an ImageProvider, providing registerFiles, registerCheck, etc?

[feloy]

I changed the pattern, for the API to provide helper functions to the extension, to help populate the response to getFilesystemLayers
cc @benoitf

[benoitf]

thanks for the big changes @feloy

I think now it's more straightforward

[cdrage]

This looks amazing and I have no issues either with the code after going through it, amazing work!

LGTM.