Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#26 2010-07-24 13:05:39

artoodetoo
Member
From: Far-Far-Away
Registered: 2008-05-11
Posts: 227

Re: FluxBB direction - incremental vs major

I'm for rewrite. All we need to keep is DB structure.


I'm not a fan of FluxBB way anymore.

Offline

#27 2010-07-24 15:08:29

adaur
Developer
From: France
Registered: 2010-01-07
Posts: 843
Website

Re: FluxBB direction - incremental vs major

Reines wrote:

I can't speak for the mod authors, but if it was me I'd probably rather 1 big update than lots of small changes.

I agree a lot with you! One big update is easier than a lot of *majors* updates.


FeatherBB - A simple and lightweight new generation forum system
Based on FluxBB, written in PHP, using Slim Framework for a proper OOP-MVC architecture.

Offline

#28 2010-07-24 17:29:38

Otomatic
FluxBB Donor
From: Paris - France
Registered: 2010-01-26
Posts: 574
Website

Re: FluxBB direction - incremental vs major

Hello,

Waiting for a "major" version would not be a problem provided that the current database is consistent or easily transferable.


Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Ghandi
An error does not become truth by reason of multiplied propagation. Ghandi

Offline

#29 2010-07-24 18:25:18

Meow
Member
From: Taipei, Taiwan
Registered: 2008-05-10
Posts: 677
Website

Re: FluxBB direction - incremental vs major

We have used 1.2 for 5 years, so I think 2.0 will not also take 5 years. We have a united team now.


Enjoy the chosen furry artworks on Chita every day.

Offline

#30 2010-07-24 21:01:36

zaher
Member
From: Damascus, Syria
Registered: 2008-07-12
Posts: 126
Website

Re: FluxBB direction - incremental vs major

Meow wrote:

We have a united team now.

Yes, that true, "We have a united team" in the past also.

I dislike MODs because i am not really php developer, so all my MODs after years need to review before upgrade it, i need to switch my brain from Pascal to PHP and start update my site tongue .

Offline

#31 2010-07-24 21:42:02

Mpok
Member
From: France
Registered: 2008-05-12
Posts: 389

Re: FluxBB direction - incremental vs major

IMO, a rewrite will be much cleaner and much simpler. Both for the users and creators of mods.

For mods, the incremental approach would mean having to make at least two updates: one for the template system (1.5), and then another one for the extension system (1.6). Thus, almost twice the same work (in time).
For users of these mods, it would be even more the mess sad : we already have mods for 1.2 and mods for 1.4 ; we would have more, "mods with template" for 1.5, and "extensions" for 1.6. All these mods/extensions being incompatible.

If one opts for rewriting, things will be clear, at least: mods for 1.x, extensions for 2.x (hoping there is NO mods for 2.x, which is less sure with incremential approach).

Moreover, as noted above, the rewriting overcomes potential problems of backwards compatibility, and thus enables a better job in the end.
And in terms of development time, it's not sure at all that the incremental approach is faster (with equal features): it doubles (at least) the time to debug (betas, RCs..., all the process).

Note : last but not least, the last attempt of an extension system was also "incremential", based on 1.x. And we all know what happened to it... wink

Offline

#32 2010-07-24 21:59:11

Mpok
Member
From: France
Registered: 2008-05-12
Posts: 389

Re: FluxBB direction - incremental vs major

Reines wrote:

I can't speak for the mod authors, but if it was me I'd probably rather 1 big update than lots of small changes.

+1 lol
A big update can be planified, organized, tested...
"Small changes" (which, moreover, would be not so small in these cases : if we have to separate the html from the code for templating, it's obviously a big change... wink) take less time but are more difficult to treat.

Offline

#33 2010-07-24 23:56:05

Ruckus
Member
From: Danville, Illinois
Registered: 2008-09-17
Posts: 12
Website

Re: FluxBB direction - incremental vs major

I would be very interested in helping with a 2.0 rewrite. With a proper template engine and extension system FluxBB could be a major competitor with other forum software while remaining small and light-weight at it's core. I also think the current dev team is a lot stronger and more organized than what we've seen in the past.

Offline

#34 2010-07-25 17:22:20

Jérémie
Member
From: France
Registered: 2008-04-30
Posts: 629
Website

Re: FluxBB direction - incremental vs major

Mpok wrote:

Note : last but not least, the last attempt of an extension system was also "incremential", based on 1.x. And we all know what happened to it... wink

I still don't. I woke up one morning and poof, it was gone. Gone with 100+ hours of work.

Still trying to understand why... WP has a pretty good plugin system, and 90% of the plugins don't need access to templating. Sitemap generator, polls, multigroup, various moderator tools, extension to the parser, various kind of upload/hosting capabilities, and so on... all these popular board plugin don't need template language.

Last edited by Jérémie (2010-07-25 17:22:39)

Offline

#35 2010-07-25 19:47:38

zaher
Member
From: Damascus, Syria
Registered: 2008-07-12
Posts: 126
Website

Re: FluxBB direction - incremental vs major

I am for rewrite if have CMS enabled tongue

Offline

#36 2010-07-25 20:03:50

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,719
Website

Re: FluxBB direction - incremental vs major

No CMS in FluxBB tongue


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#37 2010-07-25 20:16:31

zaher
Member
From: Damascus, Syria
Registered: 2008-07-12
Posts: 126
Website

Re: FluxBB direction - incremental vs major

Forgive me but, i just dreamed about full light FrontPage+News+BugTracker+Forums for developers sites simple like as FluxBB, many sites of developers use heavy ones, mixed with bugtracker not integrated, mixed with wiki with bad integrated etc...

Offline

#38 2010-07-25 20:37:07

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,719
Website

Re: FluxBB direction - incremental vs major

Hey, I was planning something like that smile
But we're getting a little off-topic. Just contact me.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#39 2010-07-26 00:20:29

viktor
Member
Registered: 2008-07-18
Posts: 14

Re: FluxBB direction - incremental vs major

on one hand, it won't attract admins if their bb engine receives heavy updates every year.

on the other hand, looking at the length of the 1.4 development process, a rewrite would take 10 years.

i like clean solutions, so if you feel you could finish a rewrite in a reasonable timespan, i say go for it. fluxbb is already really neat, so i don't think people can't live without the mentioned missing features.

just provide a stable platform, coz with this floating-all-the-time development policy noone's going to create themes and mods (or templates, plugins...).

Offline

#40 2010-07-26 05:04:55

hcgtv
Member
From: Charlotte, NC
Registered: 2008-05-07
Posts: 463
Website

Re: FluxBB direction - incremental vs major

Incremental vs Major, that is the question.

Let me share what I've gathered over the years from following the support forums for six years, and from PunBB forum admins that I've personally contacted.

1. What do we really need?
a. Better search.
b. Stopping bot registrations.
c. Spam prevention.

2. What would we like to see?
a. Sub-forums.
b. Custom user fields.
c. Separation of template and core code.

Pretty short list, not much to ask for. That means that from an admin point of view, the current code base is fine, with just 3 bullet points that desperately need addressing and 3 more that would be cool to have.

There are plenty of other forum apps freely available for one and all to download and install. It's not like FluxBB is the only game in town. Should you require more bells and whistles, then Flux is not for you, and from the start it was never Rickard's intention to address everyone's desires.

What drove me to PunBB was not the features, but lack there of. With less code bloat comes speed, less points of failure and more security. I want to install a web app and not have to worry about it, just administer it.

On the what do we really need points, there are mods available for 1a, 1b and an Akismet mod for 1c that I've been using successfully. But they are mods, makes updating a forum to a new release something you leave for when it's raining outside and you have nothing better to do.

On the what would we like to see, code for 2a was floating around when work was being done on 1.3, don't quite remember who has it. 2b is a nice feature should Flux be used as a tie-in to a CMS, all registrations could be handled by Flux, letting the admin designate what information he/she wants from their users. That leaves 2c, the big enchilada, the one nobody wants to go near. It's the biggest reason, I feel, that forums end up getting modded.

So did I answer the question, Incremental vs Major?

No, I don't think the community can give the devs the answer to that question. You see we're the end users, we look at FluxBB from an operational point of view, we're not knee deep in the code, wishing that that algorithm over there was better written or thinking should the admin side code be re-factored to accommodate Ajaxing.

Whatever you, the current devs, decide to do, well that's really up to you, it's your free time after all. But as you contemplate your next move, step away from the code, be a user.

Last edited by hcgtv (2010-08-06 14:55:48)

Offline

#41 2010-07-26 10:56:38

Gary
Moderator
From: Sydney, Australia
Registered: 2009-09-07
Posts: 232

Re: FluxBB direction - incremental vs major

It is definitely a plus to see that the developers of FluxBB are planning a major move as explained in the first post. I haven't been around this forum software for all these years, however when I did find out about it, I loved it! I am even planning a forum or two using FluxBB itself. It definitely has potential and is obviously getting more and more active every month. People are becoming more aware and I'm proud to call this community active; everyone wants to help each other and the forum software as a whole.

More onto the point though; I cannot decide whether to vote for an incremental or major update. There are advantages and disadvantages for both of course as expected. In hindsight, if the major update will take years to develop and release (I don't understand why people say it would take so long, but I may be missing something), then the staff will be constantly going round in circles as new "technology" will be brought about and everything else will be updated... FluxBB will take more time updating its software, then more updates will be need to be made for FluxBB to meet the latest standard, etc.

Also, are there specific reasons as to why FluxBB doesn't have a private messaging system or other, what other forum softwares might call, 'simple features'? Don't mean to complain, merely a query.

I would also like to offer my assistance to FluxBB if the development or any other team requires it.

Offline

#42 2010-07-26 11:06:02

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,719
Website

Re: FluxBB direction - incremental vs major

PorkoWog wrote:

Also, are there specific reasons as to why FluxBB doesn't have a private messaging system or other, what other forum softwares might call, 'simple features'? Don't mean to complain, merely a query.

May I point you to our wonderful (uncompleted hmm) unfeatures page!?

PorkoWog wrote:

I would also like to offer my assistance to FluxBB if the development or any other team requires it.

We sure need active developers - especially in case we decide to go for a rewrite. I suggest you drop Reines an email.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#43 2010-07-26 11:30:01

ethy
Member
Registered: 2010-07-24
Posts: 3
Website

Re: FluxBB direction - incremental vs major

FSX wrote:

To be honest, I like mods more than extensions.

You can't say that. You don't even know what's the extension system is going to be. I don't even know.

You mean something like Joomla extension system? Imho it's pretty bad idea. Updates are easy if you know how to use diff tool. Also you will learn a lot about engine/mods during update process. If someone doesn't know what is diff, maybe he should pick smf?

Please guys, don't go that way... 2.0? Yes! But without retardish features.

Last edited by ethy (2010-07-26 11:37:19)

Offline

#44 2010-07-26 14:49:31

FSX
Former Developer
From: NL
Registered: 2008-05-09
Posts: 818
Website

Re: FluxBB direction - incremental vs major

I never said anything about Joomla. That piece of shit makes me puke. This is my own opinion, I had to work with it for a half year and I don't like it.

Last edited by FSX (2010-07-26 14:52:54)

Offline

#45 2010-07-26 14:53:59

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,719
Website

Re: FluxBB direction - incremental vs major

ethy wrote:

Please guys, don't go that way... 2.0? Yes! But without retardish features.

What would 2.0 look to you then?


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#46 2010-07-26 21:42:47

Jérémie
Member
From: France
Registered: 2008-04-30
Posts: 629
Website

Re: FluxBB direction - incremental vs major

You can check on PunBB (1.3 branch) to see what was the extension idea at first. Kinda like Textpattern, Wordpress, or other similar things. I don't know if they are still talking about extension in this way.

Offline

#47 2010-07-26 21:47:40

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,719
Website

Re: FluxBB direction - incremental vs major

No, it would be different. The design of the extension system was one of the, if not the, most important reasons that 1.3 was discontinued.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#48 2010-07-26 22:01:22

Jérémie
Member
From: France
Registered: 2008-04-30
Posts: 629
Website

Re: FluxBB direction - incremental vs major

Franz wrote:

What would 2.0 look to you then?

If I may speak for myself, more or less what Flux is now but with a plugin system. Select a plugin, click, it's installed. Click another day, Flux and plugins are updated.

Simple, efficient.

From an user experience point of view, I would take a long hard look at Wordpress. Some choice they made don't fit with Flux (advanced javascript editing, load of ajax, a more graphical default interface) but beside these different philosophies the user experience it provides is quite impressive.

You rarely have to edit anything (beside a few files for a semi custom theme, if you want one[1]), it check all by itself if it need to be updated, it update itself, it update its extensions (including plugins) itself. Installing, uninstalling plugin is dead easy.

As for features, I would include some more compared to the current branches. Things 80% people need, like a sitemap, like multigroup, like clean verbose URI, like smart meta headers, probably subforum. Some of these are quite light, other more entrenched into the guts of the core, but again check both the software philosophy and the 80% need within that paradigm.

As for what's technically core, and what's official plugin shipped with it, I don't care at all. It's all the same from the user point of view.

[1]: I would say that it would be a pretty popular feature, but I don't think a theme system would fit with the original PunBB philosophy. It would make the software more complex (both from admin and code point of view), add an abstraction layer that would require more server resources, and if that's a must-have for a CMS-like, it's absolutely not for a forum in my opinion. Target the 80% need, and 80%+ of forums have the same underline structure. The rest is pure cosmetic, that's CSS, anyone can edit those to suit their needs. If someone need the software to do something quite different, they can handle editing files for the underlining structure.
A "skin" system, with a repository of CSS files packaged with images and few files might be useful for some, I'm not sure it's really necessary.

PS: the various tools that would greatly improve the user experience (plugin handlers Wordpress-like) are not very light, but are run by hand on a case to case basis. It would somewhat expend the codebase yes, but in one clear definite space. It wouldn't affect the server or client resources for the usual forum use, reading, writing, searching, and so on. Flux would still be light and fast.

Last edited by Jérémie (2010-07-26 22:04:08)

Offline

#49 2010-07-27 09:30:33

draders
Member
Registered: 2009-01-03
Posts: 6

Re: FluxBB direction - incremental vs major

I'm not so sure a total rewrite is necessary. What if instead you built some sort of shell around 1.4 where all pages get served from one index.php. So instead of post.php?tid=4425 you have index.php?view=post&tid=25. And since you would have to replace urls, you could add a url handler class making it easy to add friendly url support instead of the 100+ step modification that's currently required. From there you can start working on a MVC system and start converting the main pages like forum index and viewtopic keeping in mind of things like extensions. The templates for these views could even output the same html as 1.4 so you don't have to worry about updating the skins until its all converted.

Offline

#50 2010-07-27 09:40:28

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,719
Website

Re: FluxBB direction - incremental vs major

Well, a front controller is not required for MVC. Multiple entry points like we have now would work perfectly well. I haven't heard anything about that from the other developers yet, but from my perspective I agree that a front controller would be useful: it would make URL rewriting simple, as you said; but with extensibility in mind I think that it would also have benefits, e.g. when it comes to adding new pages.

I think the downside of your suggestion (or the incremental approach in general) that it seems like more work changing some bits again and again (who likes refactoring?), whereas users would possibly like the more obvious progress (though I surprisingly heard voices against that, too - too many updates). The problem is that we can't really know how long a rewrite would take. And thus, we can't really know if it is worth splitting the task up.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

Board footer

Powered by FluxBB