my sensibilities for software design is to say no to features as often as is reasonable
and pleroma triggers me in that regard

like, I'd expose an API and a few webhooks and make people compose daemons if they want some fucky shit
@kurisu i think the essence of the issue is to say no to features that don't fit your core goal, whereas the core goal of pleroma is to be as configurable as possible, which means they say no to much less features, and just have them be configurable

that's just my thoughts though
@pea i agree, but I feel configurability as a goal is not really a good goal. The end goal is to look at usecases of actual users and work out how to solve them while increasing the maintenance burden of the project as little as possible.

And I feel that specific modules and APIs for specific software is not conducive to that, it adds a new dependency to your software, and means every time that external dependency changes their API or introduces a regression or does something fucky it's on you to maintain compatibility. I'd much rather enable other people to write that glue code themselves, usually for just the version of the software that they themselves run. And if they loose interest and stop maintaining their code, it's not on me to pick up their workload, however tiny it is. Also adding specific glue code for specific projects tends to be a slippery slope towards having 1000 of these modules, more than half unused and unmaintained, often broken.

@kurisu @pea
IMO configurability is something you should do incidentally, not on purpose.

So if you're writing code, and you aren't sure how something should be handled, and making it a config option is faster and easier than trying to figure out which way is right, then by all means make it a config option.

But adding a whole feature just because maybe some day someone will want to use it is IMO a bad idea.

Follow

@kurisu @pea
However, I think this is not the case with Pleroma.

I haven't followed it closely, but to me it appears that many of its features (gohper, ssh, etc) were implemented to prove that it's possible.

Maybe they should've been external projects. Maybe they should've ended up in some kind of contrib/ directory.

But implementing something unexpected just to prove that it's possible is IMO a worthy goal.

And if keeping it around forces your software to be more flexible - even better.

@Wolf480pl @pea no, i joke about it but pleroma isn't too bad

there's not really that much glue code
Sign in to participate in the conversation
niu.moe

Welcome to your niu world ! We are a cute and loving international community O(≧▽≦)O !