On 21 November 2014 08:50, Michael Krotscheck <[email protected]> wrote: > For API clients that require access to large parts of the data set, I've > actually proposed a solution that doesn't involve the REST API at all. It's > likely that this particular spec will also be the backbone of storyboard's > federation (assuming we don't argue it into oblivion). > > https://review.openstack.org/#/c/105252/
That will certainly mitigate the frequency at which API clients scan, but initial sync, and every time the socket connection is lost, will trigger a full scan of the interest area of the client - as the spec is written today anyway. An architecture more like pubsubhubbub would mitigate that on disconnects, if that is relevant. (Basically have any subscribable thing have a last-changed field that can be read, and then api clients can sync state by reading back until the last mod time is low than their last fully-synced datestamp). Initial sync will still happen, and that may be a concern. Also, IME the clients doing full syncs as described are often naive one-shot data analysis tools. They'd likely be better served by server side map-reduce (e.g. js functions running in node). -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
