added ability to pass cached tweets (raw json from twitter api)

[grucha]

Hi,

I'm the author of django-switter - a twitter api proxy for Django (https://bitbucket.org/grucha/django-switter/)

I use cached tweets to render tweets at page load time without any additional http request.

Could you please merge this pull request so other twitter api proxies can use it too (and so I don't have to use forked version of jquery.tweet in my proxy).

Best regards, Sylwester Gruszka

[purcell]

Hi Sylwester!

So the idea of this is that you would render raw json into the javascript block which calls tweet()?

If so, then this feels wrong to me: if you're rendering everything server-side for the sake of efficiency, you should probably just render the tweet data directly into html, and avoid transferring all the redundant javascript, right? The "cached_tweets" changes effectively bypass much of the code in tweet.js, after all.

And if absolute efficiency is not the ultimate goal, then the extra http request to fetch json which is cached on the server side is not a problem.

As a result, I'm not particularly keen to merge in these changes.

-Steve

[grucha]

Hi Steve,

My first thought was to render tweets directly in the backend. But let me explain why in the end I turned into cached_tweets solution:

1. I would have to duplicate lots of jquery.tweet.js functionality, i.e. all the "3 hours ago" formatting stuff. It would be substantial chunk of redundant code which would have to be rewritten in every language/framework backend that wants to be able to use cached tweets. And then, in the frontend, jquery.tweet.js takes over control and refreshes tweets anyway after some time. So if I'm using jquery.tweet.js anyway, what's the point of rewriting it in the backend?
2. You might ask then: what's the point of using jquery.tweet.js if I'm caching (and potentially rendering) tweets in the backend? It's because sometimes cache expires and I don't want the backend to reach Twitter API in such case (adding unneccessary delay or even failure).

For that two reasons cached_tweets becomes handy. I can just use it when I have cached tweets available and fall back to another http request when cache is empty.

I hope I made you consider this once again.

P.S. I saw another pull request that was regarding caching tweets: in local storage (but I did'nt look into the code). This might be another point to use cached tweets.

Best regards, Sylwester Gruszka

[purcell]

Have you looked at the other solutions, e.g. those mentioned in #264? They all provide a server-side endpoint which can return cached json. If you want the widget to refresh automatically at some point, then you need such an endpoint anyway, and can then just use it right from the beginning. If the backend has problems reaching the Twitter API, as you suggest, then it should just return stale json when necessary.

I can sort of understand wanting to use the rendering code in tweet.js, so I'll keep this request open while I think about it, but I'm still pretty much -1. :-)

[grucha]

My backend piece does caching too (it's twitter api proxy) but I wanted to eliminate even this initial extra http request.

If you don't like this approach then I think it's no big deal and I can live with this extra request. I just thought it would be a nice addition ;-)