[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]

/hydrus/ - Hydrus Network

Bug reports, feature requests, and other discussion for the hydrus network.

Name
Email
Subject
REC
STOP
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
Archive
* = required field[▶Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webp,webm, mp4, mov, swf, pdf
Max filesize is16 MB.
Max image dimensions are15000 x15000.
You may upload5 per post.


This board will be deleted next Wednesday. I am moving to a General on 8chan.moe /t/. This board is archived at 8chan.moe /hydrus/!

File: 06ec0ffde0c293d⋯.png (577 B,128x128,1:1,Pyrus.png)

25b943 No.10128

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?

____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

bf0bb1 No.10175

>>10128

This is the guy from 8/tech/ telling you to show code or GTFO.

> UTF-8 boooo

If you do download images from Pixiv you will see why you are flawed.

> Moar tags

Already on its way to the public

> YouTube and Twitter videos

On the to-do list already

> Symlinks and secondary DB

There are winfags here so it is not for everyone… On the to-do list though.

> No client-server difference

You will regret this once someone implements a 3rd-party client/browser/viewer to work with the upcoming API

> the hideous GTK3 theme

WxPython for Winfag compatibility. Move it to Qt if you have balls.

> No "media viewer", rely on VLC/MPV

On the to-do list

> Allow users to create custom execs for each filetype

Whatever

> You could get a whole lot more complicated in the long-term by introducing a whole scripting language

Read the list of parsing scripts https://github.com/CuddleBear92/Hydrus-Presets-and-Scripts and if you think you can write a language to replace this, take a look under the hood

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

25b943 No.10194

>>10175

> UTF-8 boooo

I'll forgive you for misinterpreting my rant, but that was about characters being converted to their lower-case forms, not something needless like converting unicode to hex.

Considered the rest though, maybe I'll wait and see how good Hydrus gets.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

a6d673 No.10196

>>10194

"Talk is cheap, Show me some code" Linus Torvalds

"Release Early, Release Often, Listen to your customers" Eric S Raymond

"No problem is too big it can't be run away from" Linus Torvalds

"Prototype then polish, Get it working before you optimize it" Eric S Raymond

"Any program is only as good as it is useful" Linus Torvalds

"With enough eyes, All bugs are shallow" Eric S Raymond

"Those that can, do, Those that can't, complain" Linus Torvalds

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.



[Return][Go to top][Catalog][Nerve Center][Random][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]