Tags on photos can now have timestamps, so that if you are tagging
a video or audio you can reference a specific moment with your tag.
In the interface, this means the tag is clickable and seeks to that
point in the media.
For the user interface, I am finding I need to move away from jinja
for the object cards because it is too much hassle to keep the code
for jinja-based cards for static rendering and the js-based cards
for dynamic rendering in sync. Rather than write the same cards in
two languages I can dump the JSON into the script and render the cards
on load. Which makes the static HTML worse but that's what the JSON
API is for anyway.
I've moved the thumbnails around many times over this project
and hopefully it doesn't happen too many more. Once the database has
tens of thousands of items, the thumbnails start to become the biggest
headache on the disk. Backing up, restoring, and sharding files per
directory are slower and more effortful with separate files. In the db
means the db is a larger file, but this is disk space that was already
getting used anyway. Now it's simpler and has atomic transactions.
The initial motivation for this was to make the "more_after_limit"
feature, which would help the UI to not show a next page button when
the number of results was exactly equal to the limit.
However, in order to surface this more_after_limit status using only
the old search generator, it would have to be a special yield at the
end. I was getting tired of the special yields like give_back_params
at the beginning and warning_bag at the end, and this would be worse.
There is a lot of sideband information about the search that is now
more easily accessible when the search is its own object.
Because albums and tags have both parents and children, there's quite
a lot of redundant json when rendering each as a dict. I'd rather
improve the bulk searchability of objects by their ids than bloat
every response with redundant renderings of the same child objects.
Also, all include_* parameters are now nested inside the minimal
check so that minimal will take priority.
This helps a lot when it comes to querying for atom feeds. You can
request the last X hours of items instead of picking some limit
that you hope is high enough for the highs and wastes data during
the lows.
You want created=now-86400..now for one day.
