should allow clients to accept cached objects

[Martin Pool]

It would be nice if API clients could specify that they're willing to accept cached objects up to a certain age. For example:

  launchpad = launchpadlib.login(......, max_age=3600)
  b = launchpad.bugs['600000']

should not do any network IO, assuming that I have a sufficiently recent cached copy of the wadl and the bug.

The default should probably remain at always revalidating.

A great example for this would be if I can start bughugger in "offline" mode where it works only from its local cache.

Probably you want to be able to change this on an existing session, perhaps as a context manager, or perhaps on a particular object to say b.lp_refresh(max_age=3600) so it will refresh only if the representation is older than that.

The server probably can allow most or all objects to be cached indefinitely, and just let the client decide when they are too stale or when the cache is getting too big.

[Gary Poster (gary)]

We've discussed the context manager approach to this problem. We agree that it would be nice to have.

We also have discussed possibly wanting to be able to get a consistent snapshot of a given database revision with the webservice. It would make working with the webservice much easier to code for in situations like this one. It would also be one step in allowing support for transaction semantics.

[Martin Pool (mbp)]

On 19 July 2010 23:48, Gary Poster <email address hidden> wrote:
> We've discussed the context manager approach to this problem.  We agree
> that it would be nice to have.

For those reading it later, that would be something like

  with lp.cache_settings(max_age=3600):
    lp.bugs[1].....

> We also have discussed possibly wanting to be able to get a consistent
> snapshot of a given database revision with the webservice.  It would
> make working with the webservice much easier to code for in situations
> like this one.  It would also be one step in allowing support for
> transaction semantics.

That's kind of interesting but I see it as much less important and
probably impossible :-) I think clients need to just cope with the
fact that the db is changing. I'm suggesting a cache for the sake of
performance and eventual offline operation, not pseudo-consistency.

--
Martin