ETag support #106

Closed
revetkn opened this Issue Feb 12, 2014 · 6 comments

2 participants

@revetkn revetkn self-assigned this Feb 12, 2014
@revetkn

Have to figure out an implementation strategy that is as easy as possible for client code.

Rough idea: inside of DefaultWebRequestor we maintain a cache (SoftReferences) with "unique" request keys (maybe MD5 a concatenation of the request body and URL?) and for values, etag along with response body. Then DefaultWebRequestor could store/set etags on your behalf and pull data from its local cache if it gets a 304 response back. I'd also expose a property to enable/disable etag handling, and maybe have the cache be pluggable in case you need more aggressive clearing than whenever the GC feels pressure.

@revetkn

...to be clear, with the above suggestion there would be no changes to any code that uses FacebookClient, all etag work would be handled under the covers. So you could update RestFB to the newest version and it would all "just work" automatically.

@revetkn

Nice implementation of a SoftHashMap:

http://www.javaspecialists.eu/archive/Issue098.html

@nbartels nbartels assigned nbartels and unassigned revetkn Nov 11, 2014
@nbartels

In my opinion, only the GET-calls should use etags, because I'm allowed to post the same data at the same resource several times and get every time a new response. So the caching approach cannot work. Besides from that POST responses are more or less small.

If I fetch data from FB, I use a specific call and perhaps the response has changed or not. And the "not case" is the interesting part where we can pull data from our cache.

I suggest to implement the SoftHashMap where the value consists of 2 fields. The Etag and the response body. The key is only the checksummed URL. Perhaps even the String is enough, but unsure about that.

As soon as some data is fetched from Facebook, the http method is checked and we look in the cache for the key. If something's found the etag from the value is used as if-none-match header field. Is the response code 304 we return the response body from cache, is it 200 we update the cache, otherwise we remove the cache entry completely. Perhaps something has been deleted, so we don't need the information.

The switch, @revetkn suggested, is important, but perhaps we provide an alternative WebRequestor implementation instead. Unsure about this, too.

@nbartels

ETag support added. I added the SoftHashMap @revetkn mentioned above and got the OK from Dr. Kabutz to use it here. He made the note, that the soft references can lead to a performance issue if "overused".

@nbartels nbartels closed this Feb 24, 2015
@nbartels nbartels added this to the 1.9.0 milestone Feb 24, 2015
@revetkn

Using a new WebRequestor was a nice solution, so users can opt-in without us having to change the FacebookClient contract. Also cool that Heinz Kabutz gave the OK to use his code!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment