This change was prompted by my discovery that under DrivePool, two
files can have the same dev, ino pair. It's understandable but the fact
of the matter is I don't want to rely on inodes any more.
Hashing has the downside of speed, but considering the time investment
of tagging files in the first place I think it should be worthwhile.
I want to reduce some complexity around here, part of which is that
launch imported entrypoint imported backend, all to do some proxy
wrapping which isn't necessary for the dev case anyway. Less
layers of wrapping and importing is good. Plus I think this naming
is more clear.
When I first added album cards I left this line on the to do list
because I wasn't sure if I would wind up scrapping them. Although they
still need refinement, I know they'll be sticking around so let's
remove this.
Let's see if this inode tracking thing works out, and it might be
an adequate solution to the problem. As long as non-unix filesystems
work reliably and you aren't moving files across partitions.
Hashing is still an idea on the table.
I'm not entirely happy with the way that native drag-and-drop looks,
the transparent bit that you hold while dragging looks dumb.
Will have to look into control / shift clicking to multiselect.
Also just using browser confirm() for now since I haven't made my
own dialog for that kind of thing yet.
Alright, I got tired of confusing myself with the same-named
outer and inner package.
Keep in mind that every frontend implementation is supposed to be
its own independent project where etiquette is nothing but a
dependency. So the name backend is not ambiguous with the etiquette
backend.
I found that the strict heirarchy was not satisfying the situation
where one tag is the intersection of two others, but we can only
pick one as the parent
For example, does red_jacket belong under clothes.red_clothes or
clothes.jackets? A search for "red_clothes AND jackets" might
give us someone wearing red pants and a black jacket, so this
definitely needs to be a separate tag, but picking only one
parent for it is not sufficient. Now, a search for red_clothes
and a search for jackets will both find our red_jacket photo.
The change also applies to Albums because why not, and I'm sure
a similar case can be made.
Unfortunately this means tags no longer have one true qualname.
The concept of qualnames has not been completely phased out but
it's in progress.
This commit is very big because I was not sure for a long time
whether to go through with it, and so much stuff had to change
that I don't want to go back and figure out what could be grouped
together.
