I bet you thought this was a thread made to suck on Hydrus Dev's cock. HAHA, WRONG!
There's so many things about the Hydrus network that irritate the crap out of me, and it's clear that, as they're deliberate design considerations, they're not going to ever change. Therefore, I want to make my own. Problem is, I haven't really developed shit before, so I just want to know what I'm in for. Maybe I'm mistaken, but I'm under the impression that Hydrus Dev was only starting out when he began creating his as well, so maybe he could offer a few pointers, being already so far into his own project.
Anyway, here's some notes I've been making on how I might do things differently. I imagine Hydrus Dev has already considered a lot of these ideas before, so being more world-weary, and having lost that old shine in his eyes, maybe he could tell me why they're fucking stupid and wouldn't work at all.
Pyrus Database
- Store tags and other filesystem-related metadata in two separate databases for full reversibility. Since I consider reversibility so important, I think it deserves this level of security, to be stored in a more stable database of its own which gets written to less frequently and is therefore less prone to breakage. This secondary database will contain all forms of metadata the source filesystems could possibly support; not just the basics like filenames or creation dates, but also comments music tags, or even multi-purpose "description" fields. Users could also create custom keys such as "Likes" for archived YouTube or Twitter posts. Naturally, this level of data retention may seem redundant to many users, so it wouldn't be mandatory.
- Also store the full source paths of programs, or, optionally, just the final directory name. When certain files are "marked", they may all be stored (or at least symlinked) in a single internal directory with all of their original filenames. This would allow certain flash files, and even games or programs to function normally within the database. Naturally, these directories should be excluded when you start the server up. I'm thinking of a hierarchy like this.
db/.
db/everything else
db/symlinks
db/symlinks/(Games/(Visual Novels/))euphoria
db/symlinks/(Programs/)Hydrus Network
* "symlinks" subdirectories up to user discretion, even if they don't seem necessary to me when programs must work with relative paths for this level of abstraction to work anyway.
- No silly client-side case conversions. Come on, I mean we have the full fucking range of the UTF-8 character set here, not 7-bit ASCII. If users really feel like it, then maybe include an OPTION to use this kind of filter. With this and the previous point, some measure of reverse compatability with the Hydrus PTR might be possible, but that sounds like too much of a hassle.
- Since community spirit is important for a federated user participation-based booru project like this, maybe even throw in a third database for user ratings and comments.
Pyrus Client
- Develop a GUI and TUI in tandem, or if it has to be a GUI, at least don't use a terrible library that forces you to look at the hideous default GTK3 theme.
- Don't do anything absolutely fucking stupid like develop a garbage "Media Viewer" implement and integrate it so deeply into the operation of the program that other features must get held back for it.
- Allow users to create custom execs for each filetype, or even for entirely different database variables. If a user doesn't want to define another set of execs for their client, then they can simply write "rifle"/"xdg-open"/"whatever" into each field. Since we've abandoned the Media Viewer, which is used to untangle the messy jungle of a filesystem behind the curtains, we can go even more abstract and create variables for several client-specific factors to be passed as arguments for the exec.
%s might mean all selected files
%a might mean all files (this is dumb and dangerous)
%v might mean all files in the active view
and so on.
For example, and that is if that's the way the program works, an exec binding might look like this:
Bind Control-E:
exec 'Image Viewer.exe' – %v
Which, though it'd make a ridiculously long command, I don't think would have to be particularly RAM or CPU intensive. After all, this is the kind of thing ordinary file managers like Ranger do.
You could get a whole lot more complicated in the long-term by introducing a whole scripting language which can bring up windows in the client itself, or use if statements and the like, but maybe it'd be best to adhere to the KISS philosopy.
So about how stupid are my ideas?
