split models and commands APIs

Didn’t found this as issue. Something that i suggested in comments. For discussion.

When this library initially existed it had request models separated from CMDs. That allowed to have CMD creation logic separately from models. It should also allow do serder on request models. Example could be http://download.eclipse.org/jgit/site/4.4.0.201606070830-r/apidocs/index.html with org.eclipse.jgit.api High-level API commands (the porcelain of JGit). and other low level APIs. If somebody wants java docker client analog API, then ITs CMD, if somebody wants fill request object manually and send - “then low level”.

Starting from 1.12 docker changes POST /containers/(id or name)/start no longer accepts a HostConfig. that mean that - either we should stop supporting <1.10 ("starting container with HostConfig was deprecated since v1.10 and removed in v1.12"}).

• Either we should bundle more conditional logic. Keeping this logic in separate CMD without model imho sounds better.

PS. if API the same for 1.10-1.12 then i think we can ignore 1.9 version.

[marcuslinke]

As I stated before docker-java is low-level only. The fact we have introduced some high-level logic to commands is a workaround for a bad remote API design. We could implement high level API/commands on top of the existing low-level commands but this has nothing to do with this discussion here in my oppinion.

@KostyaSha So as I understand you want address different remote API versions with different request models? But what is with differences/changes in (http) parameters then? Letting the user choose which request model to use? This sounds like a bad idea. Supporting of multiple remote API versions is completely offtopic here is guess.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.