[Cecilia]

NB: If there's an issue with this script (too much network usage/requests to HF) then it would be appreciated if you PM'd me first to try resolve it.

Features

• Tabs just like old times.
  


• Cache for tabs using local storage + timeout on cache.
  


• Minimal requests to HF (I don't want to get anyone mad, I did ask whether I am allowed to send requests, it is allowed).
  


• Simple settings you can edit in the userscript.
  


• Loading text on initial tab/other tabs.
  


• Custom cache timeout (please don't abuse it).
  

Screenshot



Change Log

Code

v0.1a:
- Initial
- Cache for tab pages already loaded has been added (avoid/minimize network connections)
- Tabs are only loaded when needed (reduce requests)
- Settings added.
v0.2a:
- Cache properly done with local storage for persistence across reloads
- Cache timeout setting added
- Update url provided now.

v0.3:
- Code cleanup
- No more cookies, just local storage ;)

Download

• View the crummy code behind this mess...
  


• P.S: Don't load a ton of tabs if you can avoid it, each load requests to HF if it isn't in cache (~30KB per load + countless SQL queries). Cache defaults to 4 minutes.
  

[Autophobia]

Posting to save this. Out of state getting this setup when I'm back

[Cecilia]

If you used the API (rather than background requests), I don't think Omni would have a problem with it.

I didn't realise the api had a place for getting the content without an api key.
If it still requires an api key, then I'm not really wanting to do that stuff as it would require everyone to use a different api key.

As you can see, he didn't have an issue with requests being made (from the thread I posted). Apparently a lot of extensions have done it before.

[Cecilia]

In the past, Omni always has problems with extensions that make multiple requests per page.

The point of the API is to eliminate this need.

Do you think the api will ever be extended to regular members?
I thought it was only uber and above, which means people will not be able to use the userscript.

Besides that, just had a look at the api documentation a bit closer, there doesn't seem to be an efficient way of getting last post (aside from querying the thread id returned, then grabbing the last post in the returned results).
That'd mean that you would have to:
- Request to categories (once and store in cache or something),
For each category:
- Request category information to get forums inside.
For each forum inside that category + child forums inside the forums:
- Request to the forum to get the threads, find the thread that has the same lastpost value as the forum did,
- Format it all into a nice little html output

tl;dr: top level categories -> inner categories -> inner forums + child forums of the inner forums
So really, the amount of api requests needed is probably of similar query count + bandwidth used (unsure, not tested, but let me know if you want).


Kind of seems a bit of a mess if I got it right...

The amount of requests is minimal using the userscript. I have purposefully designed it that way (I know omni will not like 100 requests per page load).
I think 1 request per page load (can be turned off too) isn't too much, but that's me.