Collecting ideas for a simple board software

Discussion in 'Forum Software Development' started by \o/, May 2, 2018.

  1. Support PHP.

    2 vote(s)
  2. Support JS.

    2 vote(s)
  3. Support native hooks.

    2 vote(s)
  4. Please just don't do that.

    0 vote(s)
Multiple votes are allowed.
  1. \o/

    \o/ an oddity

    I had essentially been planning to write my own board software for years. I am currently in the process of finalizing the list of features it should have and starting to work on the boilerplate. Since I do not think that I, being a single developer, could ever reach the awesomeness of WBB, xF and IPS, it will probably not be a "suite" - more like a "better FluxBB" (may thee rest in peace).

    General information:
    • The software will be free. I suck at marketing, so I won't even try.
    • I will not use PHP. Just another PHP board would probably be reinventing the wheel and give me security gotchas on badly maintained servers. In fact, the board will be a native binary. That should be supported by all the major web servers out there, thanks to FastCGI - no additional dependencies, except those needed for compilation - on the web server required. Will also survive major OS updates because of that.
    • Guaranteed features: Attachments, a responsive UI (and theming) for both the forum itself and the admin backend, RSS feeds, subforums, a WYSIWYG editor, polls and media embedding will be there.
    • I will exclusively support PostgreSQL for the time being. I evaluated SQLite and it is not quite suitable for a sane board system. (Yes, I am aware of AsmBB and I like it, but mine will be more complicated.) I may or may not write wrappers so MySQL could easily be supported as well - later, though.
    • At a later point in time, there will be importers for some other board systems, depending on the features which need to be supported then.
    The one thing on which I am still undecided is the plug-in system. I currently have three options:
    1. The board should support JavaScript plug-ins.
      Pro: Everyone and their mother speaks JavaScript, so extending the software will be hilariously easy.
      Con: That would limit me to one language and - probably - also limit the capabilities of the plug-in system. Also, I think JavaScript is ugly to write (you might think otherwise).

    2. The board should support PHP plug-ins.
      Pro: Potentially easier porting of existing code for other boards.
      Con: That would limit me to one language and - probably - also limit the capabilities of the plug-in system. Furthermore, integrating PHP in languages other than PHP is not quite easy - I would basically have to call the native PHP binary anyway.

    3. The board should provide native hooks.
      Pro: You could write plug-ins in C, C++, C#, Pascal and anything else that can be compiled to a dynamic library. They could even be closed source - it wouldn't matter.
      Con: Writing add-ons would be slightly more complicated for the casual user.
    While I intend to provide enough features out of the box (see above), there might always be an occasional feature missing, so not having any extensibility would be a bad idea. I would have to write everything myself ... :rolleyes:

    Any input? Any volunteers for helping me realize my ideas? Any "please just don't do that" trolls? Every response is considered a good response. :)
  2. KnownHost

    KnownHost Participant

    So Troll Response... Please...

    Wait, I'm kidding! ;)

    Any particular reason for the focus directly on PostgreSQL? It's true cPanel supports it, DirectAdmin sorta supports it & Plesk supports it, but MySQL/MariaDB in terms of market share is much larger and would be more of a standard approach.

    As far as plugins go, I agree with you, as do most people I work with, JavaScript just looks nasty. PHP isn't much better but it seems to be more universally accepted so again, from a size perspective you may end up better off with PHP hooks for plugins.

    Past that, I'd stay away from native hooks for C, C++ etc. I really doubt you'll get much usage at all out of base languages such as that.

    There's my 2 cents, here's my bill for $200

    I kid i kid ;)
    • Informative! Informative! x 1
    • List
  3. \o/

    \o/ an oddity

    PostgreSQL seems to be more reliable and slightly faster especially on large databases, so I thought I can't do wrong with it. I assume that it will restrict my potential audience, but so will not choosing PHP as the language of choice...

    Thank you for your thoughts! :tup:
  4. Pete

    Pete Flavours of Forums Forever

    Except on most shared hosting that don't want binaries of any kind they can't poke at. It also severely curtails plugins, but if it's just for your own personal use I can imagine that being OK.

    If it's badly maintained, you're already kinda boned anyway, and it's not like the existing PHP etc. is going to go away. It's still potentially a vector you have to remember to protect against. (e.g. in the attachments board, don't expose filenames directly because .php files can still be run this way)

    Bake in use of an abstraction library at the start. Your life will almost certainly be easier immediately.

    For PHP plugins this is largely untrue. Most platforms have a ton of tooling and environmental expectations that simply aren't worth trying to support sanely. Heck, as an example even SMF and its forks don't have good plugin compatibility and they still have a lot of shared DNA - and trying to do it across the others as well is just a path of madness and will take up vastly more engineering time than having a decent plugin API that everyone can just use.

    This is an option in the PHP world too, and the SMF team did at one point look at porting bits of SMF to C as C extensions for PHP specifically to make it faster, but in practice it wasn't worth the benefits.

    What language are you looking at writing in? While there's scope for doing things in C etc. I'd wonder how much of a security risk there is from buffer overflows etc. that need to be caught and debugged. Doing it in Rust might be an interesting exercise.

    If you're looking for Python, the Misago project could probably use another dev.
    • Informative! Informative! x 1
    • List
  5. mysiteguy

    mysiteguy Devotee

    The vast majority of boards will never have databases large enough to matter, and in those cases the difference in performance between the two, if any, would be measured in microseconds.
    • Informative! Informative! x 1
    • List
  6. \o/

    \o/ an oddity

    Aw, I strongly dislike it when I have a mostly finished plan and people show me that it is far from being finished...

    My wording was slightly confusing here, sorry. What I meant was: all the major web server software (nginx, Apache, ...). :)

    No, I would not even consider to create any of this for my exclusive, personal use. It makes no sense to spend much time for something that just resides in a random projects folder for all eternity. Shared hosting would be mostly out of question, yes. Although I know (and am a customer of) a shared web hoster that lets you have binaries over FastCGI. But I can imagine that, since virtual servers are not quite expensive these days, the audience would be "large enough".

    You are right.

    Hmm, depends. I see some of the more "technical" web hosters already phasing out PHP 5.6 on newer hardware because PHP 7.x has become a good version and most common software has already got support for it. PHP is hard to predict though: there are numerous possible configurations of varying versions with very different modules loaded.

    Good advice, actually - I added it to my TODO list. :)

    Hm, it's been a while since I seriously wrote PHP plug-ins for platforms. In this case, the question about what to use is based on false assumptions from my side. :cautious:

    I briefly considered C++, but I decided that it would require too many external dependencies since clang, gcc and Microsoft's compiler have very different understandings on what C++ can do and what it can't do. I had a look at Rust and Go as well, but I found Rust's syntax too limiting and Go's ecosystem too tied to GitHub (= single point of failure). After evaluating Common Lisp as well, I finally settled to C, indeed. I'm positive that the usual workbench of code analysis tools will help me make not too many mistakes.

    The one thing missing from C when compared to Rust are Cargofiles for managing build dependencies, but this might be a good excuse to give Conan a ride... :)

    I (kind of) know Misago, I liked its first versions, but in my opinion its UI/UX became too similar to Discourse in its later iterations. It is probably a matter of taste.

    Thank you for this - in this case, it probably won't matter which database to start with. I'll throw a dice. :X3:
  7. Pete

    Pete Flavours of Forums Forever

    That's not what I mean. Even if you have your software as a binary on the account, you still have to remember that PHP is on the server and can be called at will, so you still have to remember to exercise precautions against uploaded files and make sure they can't accidentally be executed.

    I have seen forums taken over by improperly protected attachments systems before now.

    I hate to be 'that guy' but since much commonly written and deployed software still to this day has buffer overruns etc. in C that apparently aren't being fixed by code analysis, it doesn't give me hope that software in general can be built safely that way.

    If you're doing systems level stuff where performance is absolutely critical and where it's worth spending the time debugging the pointer magic, sure, go with C... but for a thing pushing text around, C feels like way too much of 'first build a tool so I can build a tool to have a tool to push text around with'.

    Yes, there's scope for it in the market - AsmBB's existence proves this - but I think it requires being realistic about expectations. It's never going to have a huge third party ecosystem (because high barriers to entry), or a huge userbase (again, higher barriers to entry than other platforms have) and in C, it's largely going to be something of a curiosity. If this doesn't put you off and you want to do it for the fun of doing it, please don't let me stop you - but if you're hoping to grow it into a mature product with an ecosystem, it's uphill both ways.
    • Informative! Informative! x 1
    • List
  8. \o/

    \o/ an oddity

    You mean, for file attachments? Storing a file without executing it does not sound like magic to me. :cautious:
    I should probably watch the directory/file modes though...

    I knew that someone had to come up with that. :D
    I found it rather logical to have not too much code between the thing that pushes text around and the thing that stores the pushed text. (Ha, I like how you put that.) I know it is risky, but it is probably cleaner than random PHP scripts if done right. (I do not assume that I will not make mistakes. I am far from being a perfect human.) I mean, even the WordPress guys who have quite some experience by now manage to introduce notable security issues every few versions. Admittedly, buffer overflows have become rare in interpreted languages by now...

    The performance boost is only one of the components. Most common languages are moving targets today.
    • PHP: Try to write a sufficiently complex PHP software that works on all supported PHP versions. Either you'll end up with a awful lot of "if function exists" queries or you'll just pull in a sufficiently complex framework which you will never fully understand, introducing its own problems every now and then.
    • Python: As the Py2/Py3 dust settles (do all web hosts already support Python 3?), the crowd starts to consolidate which is a good thing. However, there already are Misago on the "modern" and FlaskBB on the "classic" side of Python forums. There is no place for a third wheel.
    • Go/Rust: Write today, rewrite tomorrow. Maybe in five years or so, when both languages have stopped evolving too quickly.
    I am one of those grumpy old devs who have more fun writing code than actually using it. With that in mind, I do not want a solution that "just works", I want one which I fully understand. This is not achievable by just throwing a boilerplate (Symfony, Flask, ...) at your code. Yes, I want to do it for the fun of doing it - and I would like to see someone else caring about it. :)

    I am not so sure about that. The famous Discourse board software uses Ruby and people still use it, because they don't even need to care about the language: Just grab that Docker container and you're good to go. But why would a Docker container with a C software have a higher barrier than a Docker container with a Ruby software? (I have never done that before, but I might try that.)

    The ecosystem is why I started this thread. I can tell that those contributing to the board core are different people than those contributing add-ons. In today's WebDev world, everyone is a "full stack developer", being able to contribute bad front-end and bad back-end code at the same time. Why not separate them? :)

    In theory, C developers probably still outnumber PHP/JS developers, so this is negligible. (Ha, good that I have not chosen Lisp then, right?) However, as far as I can see, most forum software is not written for people who want to modify the original code anyway. Take the "large" boards again: xF, WBB, IPS - nobody (except the original developers) touches the giant codebase, all that's ever being done by "the userbase" is adding plug-ins and themes.

    So what I think is required to get a reasonable userbase are a shiny default theme, a sane set of default features and a "turn off your brain and click here" installation - right? :unsure: Because otherwise I may have to go back two or three steps and think about my language options again...

    (You made me think. Grr! :LOL:)
  9. Brad

    Brad Meh

    C developers typically aren't doing webdev and you aren't going to find many that want to modify forum software or run forum software written in C

    Before forum software had plug-in as a common feature most people were modifying the code directly. Anyone releasing plug-ins/add-ons is touching the code almost daily. _A lot_ of those folks only learned PHP/Perl/whatever because they had to pick it up to modify their forums the way they want to. I'm not really concerned with what other people do in their spare time and by all means write your software in C if that's really what you want to do. Just be aware that it isn't going to be used by many people simply because;

    1. Most people don't have web hosts that will allow them to run binaries and they won't set-up one just to try this software given all the other mature options they have to choose from.
    2. Most people that modify forum software either don't know C or don't see the need to use C for their forum/website
    3. Most people that write C are interested in doing things way beyond webdev (systems programming, game dev, *nix related stuff)
    4. No one has a need for C here because the benefits of it (speed) don't really matter in this case
    I'm sure I could come up with more. I'm not going to stop you just saying that you'll have a hard time convincing people to even try it just because it's written in C. It isn't going to be like Discourse, Ruby has tons of fan boys and was considered the new hot thing for webdev for a long time. Ruby isn't some obscure language no one has ever used or heard of. Ruby is easy for someone that knows basic HTML to pick up on, C is not.
    • Informative! Informative! x 1
    • List
  10. \o/

    \o/ an oddity

    Thank you. I will start from scratch and weigh my options again. Clinging to a language for the sake of it does not make much sense. It sounded well in my head, but all of you made valid points.

    (For those coming later: the poll is language-agnostic. :))
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.