Change 'hasImage()' to use inspect instead of list

[rhuss]

The problem is that GET /images/json?filter= is not documented and probably not officially supported. Also it has a bug: When you filter with a name containing one of the default registries index.docker.io and docker.io you won't match images without a registry prefix, make this call quite asymmetrically.

(the current solution is to try every known public registry name)

AFAIS a GET /images/(name)/json doesn't suffer this problem. For hasImage() one could simply check for the status code 202 and/or 404.

@jgangemi what do you think ?

[jgangemi]

lol - i just saw this. looks like filter is officially supported but nothing wrong w/ this change.

[rhuss]

Yeah, but filter is flawed /wr to the default registry part --> moby/moby#14894

Seems that they not really picked that up, also it could be that filter is moved into filters. Also, inspect seems to be more naturally than list for detecting the existence of an image. I already changed it and all the issues I had with this default registry naming vanished. So I'm happy ;-)

However, I removed some stuff (as always ;-) and made UrlBuilder consistence (it used to use a mixture of DockerUrl and String and I went back to String since I didn't see much value-add to this extra object.

[rhuss]

Sorry for being such a jackass, but hopefully you find it also a bit more straight forward. I don't mind to introduce new abstractions like argument or model objects, but only if the complexity is high enough. I still have the feeling that most of the time an image id (string) is enough, so I removed Image again. Also I think ListArgs and BuildArgs are a bit overkill when you only have two query parameters, that can be easily and more typesafely mapped to method arguments directly.

[jgangemi]

no worries, your project :)

the DockerUrl probably was overkill, esp once i started handing the args in the UrlBuilder itself.

the ListArgs and BuildArgs as an idea i stole from the spotify client. i figured now that DockerAccess was a bit more generic, it would be an easier way to pass in args instead of overloading methods in UrlBuilder. i guess if we find ourselves doing that down the road, we can revisit.