Wouldn't that feel like a breach of contract where the first response is supposed to get you in sync with the system? I could definitely see doing a different code path for the first response because you know there aren't any objects you have to compare against, etc. Or because you can reasonably expect that the first response is going to be an entirely different order of magnitude to everything else. And at some point you do have to load in the whole model to get started. Especially bad we ended up with something like the 5s watcher delay between updates and the initial model load of a large model takes 100s because we broke it up.
I'm generally in favor of avoiding any one thing growing without bound. I do want us to consider the tradeoffs. (limiting the size of the response then let's the number of responses to get up to date grow without bound) John =:-> On Jun 16, 2017 04:20, "Menno Smits" <menno.sm...@canonical.com> wrote: On 15 June 2017 at 20:10, roger peppe <roger.pe...@canonical.com> wrote: > > Looking at the multiwatcher code, I don't think it would be too > difficult to make > it return only a limited number of delta elements in any single response. > That would not necessarily be a hard limit (theoretically an individual > delta could be very large - I don't think anyone imposes limits on > name sizes, for example) but would probably be good enough > in practice. > +1 This seems like the best approach to me. - Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju-dev
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
