dotnet / dotnet/Docker.DotNet

Proposal to add a user layer to the library

Open
#492 13 comments 2 reactions 1 assignee Claimed by @galvesribeiro View on GitHub
enhancement
Dominant language
C#
Stars
2.4k
Forks
416
PR merge metrics
No merged PRs in 30d

Description

This is to start a discussion about a possible enhancement to the project.

The library already does a great job of exposing the Docker REST API to .NET consumers on a 1:1 basis of .NET methods to REST calls, and doing all the heavy lifting for transport and streaming and such. I think the next step is to provide a layer on top of that excellent foundation, to expose the functionality in a way that's more idiomatically .NET. The goal would be to provide a low barrier to entry to access Docker via .NET--even for people who are new to Docker.

Three examples to get us started:
1. `ContainerOperations.AttachContainerAsync` needs to know whether the container was started with TTY. It has no way to get that without either doing an extra REST call (which doesn't fit the 1:1 mapping philosophy) or getting it from the caller (which puts a burden on the caller). In the proposed layer, the `AttachAsync` would use two calls to the lower layer--one to get the TTY value and one to `ContainerOperations.AttachContainerAsync`.
2. `ImagesListParameters.Filters` is of type `IDictionary>` because that's the best mapping to the REST API. Someone not familiar with the REST API will have trouble figuring out how to use that. And since the class is generated code, there's no XML documentation on `Filters` to help. In the proposed layer, the options class for ListAsync would have members such as `bool? Dangling` and `string[]? NameFilter`, with documentation.
3. The return value from `ContainerOperations.InspectContainerAsync` gives information about the container, but not nested data such as the image's name or details of the associated volumes. In the proposed layer, `InspectAsync` would return a rich object. The consumer would be able to use, for example, `container.Image.Name` or `container.Volume.Where(volume => !volume.MountPoint.IsReadOnly)`. (This requires several REST calls, but I'm assuming that consumers generally aren't optimizing for speed. If they are, they can still use the lower layer for more control.)

Thoughts?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.