[X] My Assistant

Sharing this in case someone might find it useful.

[gist.github.com] EH API Support (server part)
[gist.github.com] EH API Support (client part)

The userscript (or rather, the server part) does absolutely nothing of its own.
It's actually meant to be used with other userscripts to simplify communication with the EH API.

Instead of interacting directly with the API, userscripts can interact with the Support instead:



The Support takes care of the entire communication with the EH API server, including throughput regulation, caching and whatnot.

I started writing this a while back because:
a) Having to write/send/read/parse XHR requests/responses every time you want to interact with the API is a pain in the arse
b­) Having to deal with the 25-item-limit when you have more than 25 items you want to query is also a pain in the arse
c) Unregulated API access might arguably become a problem eventually; if you keep installing scripts that communicate with the API directly, sooner or later you're going to trigger the API's flood protection (or whatever it's called)

Pros:

• Automatically handles requests with more than 25 items
• Limits the throughput of requests sent to the API
• Automatically caches responses from the API
• Reads gallery data from the cache whenever possible as to minimize the number of the requests sent to the API
• Automatically ignores (and eventually evicts) "old" data from the cache ("old" = older than 24 hours)
• Enforces a maximum cache size to avoid blowing through the localStorage quota
• Periodically cleans up the cache because why not
• Can be installed standalone or copy/pasted into another script, it doesn't matter
• Automatically detects other instances of itself and ensures only one instance is running at any given time

Cons:

• Right now, the Support limits the number of requests sent to the server to 1 per second. I'm not totally sure that won't irk the flood protection mechanism if you send very large requests (lot of galleries), but it seems to work.
• IndexedDB would probably a better pick for storage, but I'm not going near that thing with a ten foot pole.
• Some may not like how the library stores its data. Right now, the cache creates a new localStorage entry for each gallery, which means you can have up to N (where N is the max cache size) localStorage entries at any given time. But this was the easiest solution and I can't be arsed to code a better one, so heh.
• Skips a lot of input validation because I really can't be arsed. So yeah, don't send bad or malformed data or it's probably gonna explode.
• Not really a lot of error handling because, again, can't be arsed.
• Uses message-passing to receive and send messages in order to ensure inter-script comunication. This sucks no matter how you look it. Which is also why it has a client library that hides the message-passing aspect.

That being said, this is more of a pet project than anything else.
I've used it here and there for a few personal userscripts and it seems to be working swimmingly, but caution is advised.

Looks interesting. Thanks for sharing. Don't understand enough to tell if the code is good/works. Can you link those few personal userscripts you are using?:

I've used it here and there for a few personal userscripts and it seems to be working swimmingly, but caution is advised.

The code does work, what I meant was not to be overly surprised if you encounter bugs here and there (though hopefully you don't), it's a pet project so I didn't do any unit/functional/integration/whatever testing
As for the personal userscripts, they're either modifications to existing userscripts that I'd rather not make public or modifications to other existing userscripts that just rewrite the API calls to use the support instead, I can post the code if you want but they're not particularly useful

c) Unregulated API access might arguably become a problem eventually; if you keep installing scripts that communicate with the API directly, sooner or later you're going to trigger the API's flood protection (or whatever it's called)

This was my workaround for that without creating another system to handle it:

CODE

function parseMetadatas(response){
  response.gmetadata.forEach(function(dataResponse){
...
  it5.setAttribute('metadataInfo', JSON.stringify(dataResponse));

(IMG:[invalid] style_emoticons/default/tongue.gif)

Right now, the Support limits the number of requests sent to the server to 1 per second. I'm not totally sure that won't irk the flood protection mechanism if you send very large requests (lot of galleries), but it seems to work.

I'm pretty sure it's safe to make multiple requests right after another as long as you don't make more than, say, 20 at once (and then give it a bit of time to cool down afterward). My Tag Check occasionally makes ~30 requests at once and I've never seen a problem.

IndexedDB would probably a better pick for storage, but I'm not going near that thing with a ten foot pole.

The code required for it is really annoying but I ran into localStorage limits really quickly with my SmartSearch. If you want, feel free to copy the IndexedDB interaction functions (near the bottom: dbDelete, dbCreate, dbSet, dbGet), I made them to be able to (nearly) set/get storage with the same ease as localStorage (just with one more callback).

I kind of like to see an indexDB for this since a lot of that cleanup code can likely be solved with indexes. Then again, it would be quite buggy at first.

Added to the script index.