<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 21, 2014 at 8:34 AM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The only reason is that I didn't want to introduce a global variable cache in a library. The session should be a fairly long running object and i'm looking at ways we could serialize it to allow horizon/CLIs to manage it themselves.<br>
<br>
A quicker way would be to make the discovery cache an actual object and allow horizon/CLIs to handle that seperately to the session/auth plugin. I don't know which they would prefer.</blockquote><div><br></div><div>We need a generalized caching layer in all of the clients, a session/auth cache is just another instance of that.  I've been working under the assumption for OSC that I'd be doing most of that work and that it would live in OSC initially.</div><div><br></div><div>I like the idea of a cache object that the app subclasses and hands back to the Session, then anything using the Session can make the callbacks.</div><div><br></div><div>dt</div></div><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</div></div>