I can confirm that using a new daemon 1.5.0-dev (master) and a 0.6.0 client that this does not work anyways, so +1 to removing

But if anyone else comes here and wonders the client version 0.7.0 works perfectly, its kinda like the coolest thing ever (api version 1.7)

ping @tiborvass @LK4D4

ping @icecrime

I'm okay with this. But I should say that for events I moved all filtering to api. So my daemon method just returning events. Maybe we should do same for daemon.Containers()?
So, basically we call daemon.List() from api side and filtering container there. Not sure if it worth it, but I wanna make daemon package less complicated for refactoring.

I think it depends on who should own filtering. Let's say we have multiple transports, and not just http, would we want to duplicate that logic in each transport/API layer or allow the core daemon to do it in just one spot? If the logic isn't specific to the transport then I tend to want to push it down so its common code and can be reused.

@duglin it can be done by function filterConts([]*daemon.Containers, since....) outside of daemon. I'm not sure that filtering belongs to daemon package. But I might be wrong, just asking for opinions.

I understand that it can be done - its just a question of whether we want to make the caller do it as a second step or make it part of the interface to retrieve the list. If the list is very large I'm sure they would appreciate it being filtered before it got to them.

@duglin I'm not sure why they will appreciate filtering if it is pressure on garbage collector. List size is not an issue here at all.
I personally think that I want to make the caller do filtering, because why not? Decomposition and readability vs god objects/functions. I choose first.
Okay I think for this PR it is easier just to left it as it is.

yes - let's not hold up this PR for this bike-shedding conversation but just to explain my thinking....

on IRC you said: also, now without jobs we're creating superbig slice of filtered containers in addition to superbig slice of daemon.container.List()

I think its important to separate out our particular implementation choices today from the interfaces. You're correct that right now we create superbig slices of all containers and then filter it down to another superbig slice. But that's because of our choices. If we stored our container info into a DB and applied the filters as we retrieved the list of containers then there's only one superbig slice involved.

If we did what you're suggesting, then we'd always return the superbig slice back to the caller not matter what - even if the net result was just 5. In my preferred solution, no slice would ever be larger than 5. And we can get there by introducing a DB and the caller would never know that we've improved - aside from memory consumption/time. In what you're proposing, they would never benefit from the DB switch because they're always going to get superbig results even when the filter brings it down to 5.

Doing this on the list of containers isn't probably the best example because the list isn't as large as say events where we could be talking about Gigs of data. The less we move that around the better, so the sooner we can apply the filters the better. And applying it to a DB query, rather than leaving it to the caller, would be more performant, IMO.

LGTM

good to merge?

I reviewed without reading through all the debates. I dislike the var err error too but this PR overall does much more good than harm: LGTM 👍