Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

annotation resource caching should be handled by the resolver #61

Open
balmas opened this issue Jun 20, 2016 · 1 comment
Open

annotation resource caching should be handled by the resolver #61

balmas opened this issue Jun 20, 2016 · 1 comment

Comments

@balmas
Copy link
Contributor

balmas commented Jun 20, 2016

I think the resolver should be responsible for determining whether and how an annotation resource is cached, rather than this being baked into the AnnotationResource.

E.g. we currently have:

def read(self):
        """ Read the contents of the Annotation Resource

        :return: the contents of the resource
        :rtype: str or bytes or flask.response
        """
        if not self.__content__:
            self.__retriever__ = self.__resolver__.resolve(self.uri)
            self.__content__, self.__mimetype__ = self.__retriever__.read(self.uri)
        return self.__content__

This is problematic in a variety of ways ...

  1. the memory consumption could get quite huge as all annotation resources will be cached in memory after first read
  2. if the annotation resource itself is not static, such as might be the case with a remote resource served via HTTP, there is no way for it to be refreshed

Probably the resolver should be configured with a cache provider, and it should be up to the resolver to figure out when to refresh the cache (e.g. for an http retriever via cache headers, for a local resource by date/timestamp/file size, etc.)

@PonteIneptique
Copy link
Member

Agree with the general idea, resolver should have the ability to get a Cache instance fed up to them on instantiation. Great idea.

As for the RAM issue, it is not totally correct. What you describes is the case in a non quite developy environment, where there is one thread which never sleeps. Basically, bad configs (heroku) or flask default .run(). I do not think this holds true for balanced / right envs

@PonteIneptique PonteIneptique modified the milestone: 1.0.0rc1 Feb 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants