Previously, the whole walk tree was returned. This can be convenient
because you get the whole descendant tree all at once, but it's
unusual since all the other individual .json endpoints only return a
single object, not a list.
The cached_endpoint decorator was detecting that the response content
kept changing, so it never returned 304. Oops. At the moment the client
doesn't even use this key, so if we need it back we can use the etag or
another http header.
The word caching can be ambiguous, and what's worse is this file
previously contained a decorator for server-side caching of a
response and a class for client-side caching of files. It was
confusing. This new separation and naming should make it easier
to find what you're looking for.
Previous called get_data which is dangerous for large but
indeterminate response sizes, and the bail chain was more
difficult to reason about than a simple should_gzip true/false.
Previous version had a bug when the URL contained percent-encoded
spaces because url.replace() was looking for spaces and not replacing
the %20. Constructing the url from parts is more reliable.
I was adding messages as strings because that's how they get shown on
the web interface. But it's better to return the real exception objects
and have the interface deal with it.
This prevents the specific tag from being included in the results in
the first place, and has the knock-on effect that the descendants'
lines won't all start with the parent tag's name.
The current system has bad performance when you've got 100,000+ tags.
I discovered that when the server returns 304, the browser gives the
ajax a 200 with the full response, and it's not clear to me if js can
know it got a 304. So, the tag set is being fully re-parsed from the
response on every page load. I was thinking that I should store that in
IndexedDB to avoid the parsing step, but... since the JSON.parse is
done by my common.get before it hits this function, it's meaningless.
Not to mention I still have to rebuild the datalist on every page since
of course that state isn't shared between tabs. Not worth the DB stuff.
We'll see what happens next.
This experiment of bringing Photos and Albums closer to parity in
search is going well so far. I have found some situations where it
is nice to only get albums back from search results.
There was always some semblance that two blank lines has some kind of
meaning or structure that's different from single blank lines, but
in reality it was mostly arbitrary and I can't stand to look at it
any more.
Foolishly, I was checking the length of the outputted easybake format,
which included lines for synonyms and multi-parent tags that shouldn't
be part of the tag count.
I'm currently running an experiment where albums are also included in
search results, but they don't cost you any of your limit parameter.
So the len(results) was often bigger than limit and tricking this
paginator into thinking we needed a next page when really we didn't.
This workaround can be undone when I decide how to make the album
results more official.
I discovered that werkzeug stores cookies in lists, with its .get
returning only the first item of the list. By converting the cookies
to a plain dict, I was breaking that functionality of cookies.get.
So, using werkzeug's MultiDict is the correct choice.
I've been thinking about this for a while but couldn't think of
the perfect way to implement it. I still haven't, so instead I'm
just starting with something and we'll see how to improve later.
At any rate, I can update the rest of the system to expect Albums
coming out of search so that if I ever have a better algorithm
everything else will already be ready for it.
For this first experiment, just any photos that are part of an album
will send that album out as a result. It doesn't even respect the
limit parameter, it's really just to see how it feels to use.
