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

Per page caching #58

Open
zverok opened this issue Jan 3, 2016 · 4 comments
Open

Per page caching #58

zverok opened this issue Jan 3, 2016 · 4 comments
Milestone

Comments

@zverok
Copy link
Contributor

zverok commented Jan 3, 2016

Idea is:

Infoboxer.wp.get("Argentina") # gets page from API
Infoboxer.wp.get("Argentina", "Bolivia", "Chile") # gets 2 pages from API, one from cache
Infoboxer.wp.get("Argentina", actual: true) # gets from API
Infoboxer.wp.get("Argentina", cache: 2.weeks) # gets from cache if newer than 2 weeks ago

Actual questions:

  • real, consistent, reasonable API (including global and per-site settings);
  • where and how to store data (in YAML files, probably? gem's folder, or system-wide /tmp/infoboxer?)
@zverok zverok changed the title Per page cacheing Per page caching Jan 3, 2016
@zverok zverok modified the milestone: 0.3.0 Jan 4, 2016
@rileyr rileyr mentioned this issue Mar 6, 2016
@rileyr
Copy link

rileyr commented Mar 6, 2016

It looks as though molybdenum-99/reality#16 has been closed in favor of molybdenum-99/reality#43. The first issue had indicated that the caching should Infoboxer's responsibility, but the latter reverses this. I tend to agree with the first; if Infoboxer is providing the data access layer for Reality, the caching behavior seems like it belongs in Infoboxer.

@zverok
Copy link
Contributor Author

zverok commented Mar 6, 2016

That problem has TON of sides, as it turned out with time.
Here are some of them:

  1. First and foremost, Infoboxer is not only "backend for Reality", there can (and eventually will) be specialized clients for Wiktionary, or, say, Wikitravel through it; or demo projects about Game of Thrones infographics based on fan wikia. From this point of view, caching feature for infoboxer is definitely useful and will be really welcome!
  2. Thinking of caching in Reality, my mind is constantly changed (moving up by abstractions stack: Faraday→Mediawiktory→Infoboxer→...?). Currently, each reality entity consists of at least two parts (wikipedia and wikidata), and if Wikipedia part can be cached on Infoboxer side, what about Wikidata?.. And, when solution for Wikidata would be made somehow, how to make it uniform (with fine-grained per-entity control, with uniform cache folder setting and so on)?.. And there would be more backends eventually, so caching-strategy-inside-backend will became, like, less and less reasonable?..
  3. Though, there may be some reasonable compromise (with Reality actually using Infoboxer's caching somehow, if it would be flexible enough)
  4. Though2, if you are more interested in Reality more than in Infoboxer, I'd advice to try to think about caching in Reality context at first.

Sorry for long (and possibly discouraging) answer.

@rileyr
Copy link

rileyr commented Mar 7, 2016

Each of those points makes sense. Perhaps one could argue that caching could be in both libraries, as it would make sense for Infoboxer to provide this behavior for general use.

I am more interested in Reality, I'll focus my efforts there.

@zverok
Copy link
Contributor Author

zverok commented Mar 7, 2016

Thank you!
Yes, I think eventually caching should be in both libraries.

Looking forward for you contributions.

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