Cache Hackathon Q & A

Q1: What is the reasoning behind wrapping Caches and reducing their interface with WerkzeugCacheWrapper?
A1: The major reasoning for Nautilus wrapper was to be able to move from one Python framework to the other. If you look at Nautilus, unlike Nemo, it has been developed in a way it is made of the Flask Extension and the special retrievers. At one point in the future, the idea was to separate both in two different repositories. Flaks Nautilus would remain the flask app and the resolver would find itself a new home. With this in mind, having wrappers for cache seemed to be a good idea as it opens up other use of the codebase in other frameworks.

Q2: Is there a reason to use capitains_nautilus.cache.BaseCache rather than the Werkzeug implementation?
A2: Yes and No. Yes because this would unify the caching system. No because I would rather avoid this kind of dependancy between Nemo and Nautilus for the moment. Generally, no because Nemo, unlike Nautilus, uses only Flask and so Werkzeug. This does not mean that, for the app initiator, it is impossible to use the same object, in its true form and in its wrapper.

Q3: Do you have any profiling/benchmarking on the performance of get_text,get_passage and transform in r_passage?
A3: No. I would recommend to see this with https://github.com/nvdv/vprof/releases/tag/v0.33 that I used in another project. I would also recommend two different benchmark : functions used without HTTP instantiation (direct calls in some python script), http request benchmark. I found artillery to be a great tool for http benchmark ( artillery quick --duration 60 --rate 10 -n 20 http:// )

Q4: Would r_passage be used in document-level queries, e.g. when requesting the TOC for Smith?
A4: The route for that is r_version. This content should be cached separately (get_reffs() and .chunk()) so that we could finally see a default_prevnext derivative reusing the original chunk().