To add to Vlad's comment above: The major win was in being able to create a simple API which inherently computes update -> cache invalidation probability taking into account the semantics of the item being cached and its relevance to the query. To be able to do this explicitly via heuristics leads to bespoke effort for each new and modified query.
With Spiral, we were able to approach this top down as a classification problem.
e.g.
If you have a cached query for "Friends that liked my post", the Spiral classifier quickly learns that "Post Last Viewed At" or "Post Last Modified At" is not relevant to this via the feedback from the caching code.
Pre-spiral, this was expressed via a curated blacklist/whitelist which had to be recreated if the query characteristics changed.
Thanks! Working on the timeline feature. The temporal data and diet/size tags need some clean up - a tedious work via an offline tool with RegEx and some nltk elbow grease :)
I built PaleoCodex as an online interactive encyclopedia for Dinosaurs and other prehistoric animals for my six year old using wikipedia data.
He is a big dinosaur buff and wants to be a paleontologist when he grows up. His project brief was "Build a pokedex... but for dinosaurs"
Still kind of a WIP (Search is very basic and Text to speech / Listen feature may not work on iPhones, works on iPad/Nexus and Desktop using Chrome and Safari) and very much a weekend hack.
Built using python, tornado, wikipedia data and the skeleton html5 boilerplate. Uses ResponsiveSpeech for text to speech.
Enjoy! (and do send in your comments and suggestions)
the naked pointers are inside an internal kv namespace and are a convenience/carry over from the previous implementation (I've covered the justification for the way it's written in a comment above).
the TL;DR is that it is written the way it is to achieve constant time remove/remove_and_add_to_end operations which is not an erase+append but more like an unlink/relink operation.
the kv::List is not intended as a generic linked list implementation like std::list.
The reason for the specific implementation is to get constant time removal and remove-add_to_end operations. Truth be told, it is a hold-over from the previous implementation. I shall be writing benchmarks for this next up and shall revisit the decision on whether or not to use std::list soon-ish :)
The : private NoCopy is just to block the copy constructors.
Also, keep in mind that most of the library is templates, which need to go in the header files.
BTW, most of boost is header-only :) e.g. boost/noncopyable.hpp would give you a header only equivalent of the NoCopy class I wrote.
I've always felt weird about having to include some big-arse library for just using a simple container, so for things like this I prefer to write header-only versions.
header-only usually means there's one or more .h/.hpp files that you can include in your source. There's no source file or library to compile and include
e.g. if I had Hello.h and Hello.cpp, you'd need to either add Hello.cpp to your make/build or build a library and link to it.
We paused and looked at each other for a minute and then we burst out laughing.