The future of FluxBB

Gil · 2009-01-11 20:14:07

FSX wrote:

Gil wrote:
And it seems that you are thinking that each software should not be easy to install, modify (with some limitation) and use. It is strange!
I haven't said that. At the moment FluxBB is really easy to use. Modifying is a bit harder, that's why there is (coming) an extension system.

If extension system is coming (whatever is the version, 1.3, 2.0 or 3.5, it's perfect, and I do not have to add another words . It was not totally clear for me, with the 1.3 abandon; and I just though that for some people extension is not truly useful.

I originally said that a user who would like to use the software has to do some effort to get to know the system.

Yes, yes, but don't forget that for some peaple, using a computer is an effort, and installing a forum a huge effort. Opening an editor to modify a file - even with documentation or help - can be beyond the limits. And a gardener, an old person or a disabled one should be able to do, as easily as possible. I'd like that FluxBB become also the simplest forum to install and to manage, as pun/flux-BB was the fastest and lightest. Because I love it

Actuboard.com · 2009-01-11 20:54:46

Hello. Could you tell me if the FLUXBB version 1.4 will integrate the URL REWRITING as it was said under version 1.3. Because this fonction would be really helpfull. Thanks

ScottyDoo · 2009-01-11 20:57:41

I completely understand all the decisions made, and what I would love to see to help those of us that had already moved to 1.3 in a production environment (our fault I know) is if someone could help build a tool to convert our 1.3 DB back to 1.2. As of now I'm stuck in 1.3 unless I want to lose 6+ months of posts and go back to my backup of 1.2.

pjalar · 2009-01-11 21:17:49

ScottyDoo wrote:

I completely understand all the decisions made, and what I would love to see to help those of us that had already moved to 1.3 in a production environment (our fault I know) is if someone could help build a tool to convert our 1.3 DB back to 1.2. As of now I'm stuck in 1.3 unless I want to lose 6+ months of posts and go back to my backup of 1.2.

Connor wrote:

The database structure should be very similar, I think 1.4 will probably be released with a script that will update from 1.3 or 1.2, 2.0 will probably be released with a script that updates from 1.3 or 1.4 (if there is demand a 1.2 -> 2.0 script will probably also be created). We don't want to leave users stranded with a database incompatible with any current version

ScottyDoo · 2009-01-11 22:18:53

pjalar wrote:

Connor wrote:
The database structure should be very similar, I think 1.4 will probably be released with a script that will update from 1.3 or 1.2, 2.0 will probably be released with a script that updates from 1.3 or 1.4 (if there is demand a 1.2 -> 2.0 script will probably also be created). We don't want to leave users stranded with a database incompatible with any current version

That only helps for future upgrade, I'm talking a downgrade.

Connor · 2009-01-11 22:20:35

1.4 will be out very soon though, so you can go from 1.3 to that.

ScottyDoo · 2009-01-12 01:56:27

Connor wrote:

1.4 will be out very soon though, so you can go from 1.3 to that.

I suppose I should have read more closely...

So 1.4 is based on 1.2 and will be released in the 1st quarter of 2009 (very soon as you mentioned) and you will have an upgrade from 1.3 to 1.4.

Got it now, thanks pjalar and Connor. It apparently didn't click when I first read it.

Actuboard.com · 2009-01-12 16:20:39

Why have you abandoned the idea of "rewritting url" in 1.4 while it was in the 1.3?

Franz · 2009-01-12 16:23:04

Because 1.4 is the development of 1.2, not of 1.3. 1.3 will be developed to 2.0. Because that will take some time, 1.4 will first be released with the most important features ("URL rewriting" is not one of the most important ones).

Pedro · 2009-01-14 00:41:05

As I was reading about this cool software called elgg. I came across this concept that might be something to thing about for fluxbb 2.0.

A generic datatype that can be be inherited and therefore allowing the extension developer to create data entities without touching the physical database structure. This is not a critical feature, but it sounds really neat and I believe it could add multiple advantages.
It would prevent compatibility break downs with other extensions like backup related stuff. It would also improve the deployment of many extension if for some reason the admin has limited access to the database.

It is perfectly possible to implement such a feature without changing the current extension system. In fact this can be done as an extension itself.

Any thoughts about this?

For more details, please refer to:
http://docs.elgg.org/wiki/Getting_Start … evelopment

Last edited by Pedro (2009-01-14 00:42:15)

Smartys · 2009-01-14 01:34:33

Pedro: That looks like database normalization taken to the extreme. They say that everything in the software is considered to be the same, the only difference are some metadata attributes. I don't see how it helps conflicts between plugins (what I assume you mean by compatibility) and I don't see the advantage for admins, since you need to have CREATE TABLE privileges in order to install the software. You could rewrite FluxBB that way. Users are the same as forums, after all, except for the fact that they're not similar in any way except in that they can both be considered objects.

Seriously though, I see the advantage if you want to slap a line in your feature list that says "easily and infinitely extensible." However, that's not the best way to be extensible. It may make your plugin development more accessible (since people don't need to know SQL) but your performance is going to be much worse because you're sticking everything in the same table and relying on joins on unidexed columns.

Pedro · 2009-01-14 02:32:51

Yes, one could write fluxbb entirely like that. Not the most practical/usable/realistic approach, but it would for sure be a cool proof of concept. Sort of just jamming with limits of the technology

I too, if I should be honest, don't look at this as a must-have. In fact is not even something I would strongly recommend for fluxbb. I just thought it was worth the discussion, that's all. I mean, the extension system hasn't been really tested, one cannot tell for sure what will be its most restrictive characteristics without getting feedback from a reasonably large user base. Who knows if or when this, or whatever other feature, will be necessary?

I can think of some situations where this could be useful, but they're really few. A hosted service for example, could take some advantage of this. What I had in mind was absolutely _not_ slaping a sexy statement on the feature list.

The performance issue you mentioned is for sure the Achiles' heel of this model. If I should think about it more carefully, I would agree with you after all, It would not fit so well in a software that aims to be fast and lightweight rather than having all those features that 1 out of 1000 users need.

Sorry then, it got impressed by a practical implementation of a rather cool concept.

Smartys · 2009-01-14 03:04:43

Pedro: Don't be sorry and don't let me stop the discussion. It IS an interesting approach to flexibility and extensibility and is definitely worthy of being discussed, especially considering the development of 2.0.

Maybe move it to its own topic?

qie · 2009-01-27 02:39:28

so does utf-8 support or not support make any difference?

Smartys · 2009-01-27 02:40:05

Yes

Pedro · 2009-01-28 02:27:11

I am not sure this has been discussed before or not...
The views will be isolated finally. What about the 'models'?

Flux could go all the way to an MVC design. Fluxbb code is easy to follow and tidy, but i think it could get even tidier, and one wouldn't need to sort among database queries, output generation and business logic to find a specific spot.
I strongly encourage that, it doesn't require really much code rewrite, it's more a matter of sorting the existing code in a specific way.

MattF · 2009-01-28 23:37:47

Pedro wrote:

Flux could go all the way to an MVC design. Fluxbb code is easy to follow and tidy, but i think it could get even tidier, and one wouldn't need to sort among database queries, output generation and business logic to find a specific spot.
I strongly encourage that, it doesn't require really much code rewrite, it's more a matter of sorting the existing code in a specific way.

Any good examples of the MVC type design you're referring to? Just out of personal curiosity. All implementations/variants I've seen so far appear, (from my perspective), more awkward with regards to implementing alterations. That may just be due to me not having seen a tidy implementation yet, however.

Pedro · 2009-01-29 00:42:58

Well.. any application built on top of one of many php MVC frameworks out there.
To be honest I can't point one PHP project that follows a strict MVC design, but I don't know the source code ha of many applications, specially when it comes to newer applications that poped up after the MVC hysteria.

Sorr I cannot be so specific... google -> php mvc

MattF · 2009-01-29 00:47:36

Pedro wrote:

Well.. any application built on top of one of many php MVC frameworks out there.
To be honest I can't point one PHP project that follows a strict MVC design, but I don't know the source code ha of many applications, specially when it comes to newer applications that poped up after the MVC hysteria.

No worries. I just wondered if there might be one, (or more), specifically, that had a reputation for being clean and compact, both from the use and code points of view.

Pedro wrote:

google -> php mvc

I try to avoid doing that if possible. I spent over half a day getting sidetracked last time I used that method of having a quick dig around. Those damned internet search engines.

Pedro · 2009-01-29 17:15:41

I spent over half a day getting sidetracked last time I used that method of having a quick dig around

That thing you did is called 'Learning'

Anyways... to put it short, every data access stuff would be inside Models, the presentation logic would be defined in the Views, and the Controllers would be sort of like the engine that puts everything together. That's what MVC is in a nutshell.

It's not a fancy way of programming, it concerns mostly, the way the source code is organized.

This might not be of the interest of punbb. After all punbb is a web bulletin board software and that should be it's main goal. But I strongly believe this can be of great value in the future.
This would make it a lot easier to use pretty much any type of data storage. Flatfiles, googledatastorage, a distributed hashtable, etc.

I would like to hear more opinions on this.

Last edited by Pedro (2009-01-29 17:23:12)

MattF · 2009-01-29 19:47:17

Pedro wrote:

I spent over half a day getting sidetracked last time I used that method of having a quick dig around
That thing you did is called 'Learning'

It usually isn't anything one could call learning. I always end up looking at something totally unrelated and useless. God knows how I end up on those tangents.

Pedro wrote:

Anyways... to put it short, every data access stuff would be inside Models, the presentation logic would be defined in the Views, and the Controllers would be sort of like the engine that puts everything together. That's what MVC is in a nutshell.
It's not a fancy way of programming, it concerns mostly, the way the source code is organized.
This might not be of the interest of punbb. After all punbb is a web bulletin board software and that should be it's main goal. But I strongly believe this can be of great value in the future.
This would make it a lot easier to use pretty much any type of data storage. Flatfiles, googledatastorage, a distributed hashtable, etc.

I was thinking along the right tracks, it would appear. Personally, I've never yet been able to see the real use for those other than having a common, familiar base that you can use on completely different projects. I suppose, however, if the templating system is indeed going to be a feature of 2.0 that some form of framework along those lines will be necessary rather than merely a consideration?

fmimoso · 2009-03-04 10:13:34

Some considerations of the developer of another forum software about the development and release of a new version.

JFYI.

Forums

#201 2009-01-11 20:14:07

Re: The future of FluxBB

#202 2009-01-11 20:54:46

Re: The future of FluxBB

#203 2009-01-11 20:57:41

Re: The future of FluxBB

#204 2009-01-11 21:17:49

Re: The future of FluxBB

#205 2009-01-11 22:18:53

Re: The future of FluxBB

#206 2009-01-11 22:20:35

Re: The future of FluxBB

#207 2009-01-12 01:56:27

Re: The future of FluxBB

#208 2009-01-12 16:20:39

Re: The future of FluxBB

#209 2009-01-12 16:23:04

Re: The future of FluxBB

#210 2009-01-14 00:41:05

Re: The future of FluxBB

#211 2009-01-14 01:34:33

Re: The future of FluxBB

#212 2009-01-14 02:32:51

Re: The future of FluxBB

#213 2009-01-14 03:04:43

Re: The future of FluxBB

#214 2009-01-27 02:39:28

Re: The future of FluxBB

#215 2009-01-27 02:40:05

Re: The future of FluxBB

#216 2009-01-28 02:27:11

Re: The future of FluxBB

#217 2009-01-28 23:37:47

Re: The future of FluxBB

#218 2009-01-29 00:42:58

Re: The future of FluxBB

#219 2009-01-29 00:47:36

Re: The future of FluxBB

#220 2009-01-29 17:15:41

Re: The future of FluxBB

#221 2009-01-29 19:47:17

Re: The future of FluxBB

#222 2009-03-04 10:13:34

Re: The future of FluxBB

Board footer