Forums

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

You are not logged in.

#1 2012-04-14 10:54:54

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Yii framework + devs :: alternative path for Flux 2.0

As most probaly know, myBB is going Yii and phpBB is incorporating symfony to an extent. phpBB is a way off till there next release. I'm not sure how far myBB has progressed.

Should Flux join the bandwagon and jump on a framework?

Here are a few arguements:
Yii will add memory usage. Somewhere around 3mbs.
Yii will add over head, RPS will drop.
Yii will require learning a framework!

Got all the negatives put aside, so lets consider some benefits.
A chance to migrate to a modern architecture!
Ability to expand out and allow to you to build a site where the forums are a module.
Still be able to run just a "forum"
A full active community that backs the framework compared having to maintain a home brew solution.

Here's a few extra thoughts:
What I'm proposing will also allow you to have widgets and other goodies that WP / drupal people enjoy. However, a full hook system is a bit more work than you'd think.

Why?
Well, I've been planning to build a fourm for my own project. I have also come across a fee others in the Yii community who have been wanting a useable forum that acts like a module for their system.

Myself and another Yii user thought building a useable base that we could give back to Flux would be an exciting adventure. Actually, if the flux community were to accept pur proposal we would thrilled to be working towards our oen personal goals that will also benefit a project that we really want to support!

At the moment, there are 2 of us but we might be able to bring in a few others.

Personally, last year I tried to port Flux to a MVC. I have up after 1 day. Flux is a wonderful package on it's own but a bear to port. Those of you who have opened the code will probably understand why.

Conditions?
A change of licence to Apache 2; possibly BSD. We appreciate the GPL but the other 2 fit our beliefs.
And, support from you!
Oh! Github!

Why not on your own?
We simply want to supoort Flux!

But Flux will no longer be what we love!
Yes and No.
It will change and that is why I have come to you! To help make what we're doing to become a modern Flux.

So ... What do you get?
A nice warm feeling smile
And,
We need to build a solution anyway, and if we can get you on board we can go back to focusing on own central projects after most of the work on this has finished. A change of hands so to say.

Code?
Saved this for last didn't I wink
Sorry, I'm still working on normalizing the db schema and we have just started discussing the layer between Yii and the forums; boring stuff like user management, roles and permissions. I have also researched a few goodies too!

Offline

#2 2012-04-14 13:55:23

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

Re: Yii framework + devs :: alternative path for Flux 2.0

Hi,

I do not want a forum that would require to integrate into a "framework". I do not want any "framework" for my sites.
I want a forum lightweight, simple, without a whole bunch of stuff and stuff that used to almost anything, but who are there for what it is "fashionable"!

What counts is the effectiveness and content, not the bling-bling.

"Why make it simple when it can be complicated! "


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

#3 2012-04-14 16:15:34

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Re: Yii framework + devs :: alternative path for Flux 2.0

Ah yes, that is a point that I might not have addressed properly. What I'm proposing can also be run as a simple 1 off forum or as you said a "bling bling" option.

You still get the benefit if needed, to have the ability to expand!

I believe very much in a simple and function approach.

So, what is a framework?
Basically a set of organized functions that somebody has decided to be in a package - framework. Basically a new term for an old concept. Like "cloud" wink Sounds better than "hosted service on the internet".

Even though I'm proposing a switch of base code for Flux, I'm very much in agreement with you.
My goal is something that even my mother would know how to use. Which is pretty much the point for most people. They don't care what goes on in the inside as long as what they are using is easy to understand and easy to use. Like a TV smile

Offline

#4 2012-04-14 21:54:22

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 5,876
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Thanks for the detailed writeup, SapporoGuy!

Otomatic wrote:

I want a forum lightweight, simple, without a whole bunch of stuff and stuff that used to almost anything, but who are there for what it is "fashionable"!

That is pretty much the point I'd like to make. FluxBB is focused on being as light as possible (well, almost) and frameworks - basically per definition - always come with not-quite-so-essential stuff baked in. Actually, Laravel is the first one I've seen that seems possibly simple enough.

In your response (@SapporoGuy), you seem to address that, but then - if I get you right - you only talk about being light and easy on the interface side.

On the other hand, integration is an incredibly important goal for us. I believe that what we have planned for 2.0 will make integrating FluxBB with sites easier than ever - and not only on the design level (which is incredibly simple already), but also on the data level (API'n'stuff). The front controller architecture should also make baking FluxBB right into your site (like a module) easy. And that is why I hope we don't need the overhead of a general-purpose framework.

That is also where I'd highly appreciate your input, as you seem to be interested in such thing. What do you expect of integrations like this? What is essential etc.? (Maybe make a separate topic about that. Or I will.)

Hope that makes sense. (It's not a no, never - just my personal statement.)
But keep pushing us smile


fluxbb.de | develoPHP

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

Offline

#5 2012-04-14 23:07:57

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Re: Yii framework + devs :: alternative path for Flux 2.0

Well, that is the crux of the matter so to speak. Flux, as is, is great! But if you're considering to move on to the next step you end up with a choice:
A.) do we continue with what we have already knowing what is going to needed to get it done
B.) knowing what needs to be done and weighing the costs against starting from a fresh point and bite the bullet

2 examples of this would be:
A = windows
B = osx

Both will end up in a similar place but the path taken is different.

I am also personally at this very same cross road. But my project is already MVC and OO. So, moving to php5.3 / php6 is just a matter of weeks not months or a year.

It's not about being close to bleeding edge nor is it about picking up on the latest hipster fashion but rather thinking about why Apple is actually in a very smart position. Which obviously comes from what their user base is going to be in 3-5 years. 3-5 years is enternitu for most software projects? I remember when vB was nothing and UBB and phorum were the go to solution.

Some projects like oscommerce have held on but even now the writting is on the wall and I really think Harald knows this so development is virtually nothing.

So, while finishing up my project in February I was already planning my next move. The framework that my project is based on is just too limited and warrants enough recoding that I might as well just support bugs and prepare for the next version which will allow me to expand at a moments notice compared to another architecture rewrite.

I mentioned my failure to port Flux to MVC. The basic reason was that I would have ended up refactoring Flux and then move from there. Good or bad is not the issue but rather the point of going back to the 2 choices - start fresh with a solid thought about what the next generation archictrcuture could be or invest the time to make the current code to fit a new agenda.

Even though there has been lots of discusion about the difference between the monolithic kernel of linux compared to the microkernel that powers OSX, Apple's choice allowed them to move quicker and adapt faster. Android is no longer behind too though!

I made my choice to go Yii because I won't have to worry about my base framework. I'll also benefit from a huge community support my product for me for free! This allows me to spend my valuable time working on features that my users need and will need. I just have to live with some decisions that ate out of my control but even so, the benefits far out weigh my gripes.


Actually, I started off with the demerits of Yii right from the start; added weight and added memory usage. Yii is a lazy loading system so it's not as bad as zend or symfony. You can even prune Yii to a lite version but it won't be as light as silo that symfony offers!

Site integration?
Well, I haven't read any of the requests here but once you have Yii running what stops you from just using it as your base? Some extra work? Something new? Not intetested in being up-to-date?

I mentioned that I'm working towards the forum being a module. Which means that you'll already have most of what you need to run a site too! SEO, forms, contact page, basically the essentials.

I also mentioned about aiming for a WP / Drupal enviornment. Definitely won't be as complex as Drupal and not as bloated (not site if bloated is actually the real issue with wp).

Ajax, json, api and restful will basically be already in the box.

Essentially, a system that most users will be able to use be it a lite forum or modified and massive like vB. My thoughts are to be a lite forum that users can modify up to what they need rather than what I think they need. One size fits all is really difficult unless you have a well thought out core (framework) that can expand with plugins and hooks. Yii doesn't really have that all emcompassing drupal effect so developers can navigate in the direction they feel like without having to work in the confines of what the "masters" have ordained for you.

Was a serious intetest until I realized I'd have to wait too long and risk too many architectural changes sad


Overhead of general purpose framework:
It's a trade off honestly. Bake your own or flavor the variety that sort suits your purpose, people are always going to want to play chef and as they say, "too many chefs spoil the stew". Or you could be tied up in commitee; windows, phpBB and several other projects I've seen.

In general, I'd say many people barely have a grasp of the benefits of MVC let alone a framework. It's just a bunch of code that makes life easier. We all drive cars that have a engine, a steering wheel and 4 tires wink Which is how I see a framework, be it a CSS framework like blueprint, foundation ... Or even one of the most famous frameworks that most people these days can't enjoy the web without - jquery!

Now, I'm not saying there is anything wrong with writting a few pages in html and writting your css! Actually, a few pages makes more sense to be just only that! But rather once you go beyond those few pages, a lite framework makes life easier and when you start looking at more features stepping up to something more heavier makes sense. Using a minus screwdriver can work on a plus screw but wouldn't be smarter to use the right tool for the right job?


-----
I posted here because of brief experience with flux code and think that what we're working on fits most of your needs. Of course, I could be wrong but I didn't post here to cause a useless problem for the devs or the community.

Just trying to be helpful:)
But in a very long, long "novel" like way wink

Offline

#6 2012-04-14 23:09:16

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Re: Yii framework + devs :: alternative path for Flux 2.0

Ooooh! That is long!
Been posting on my phone ... Hmmm better try to be less windy smile

Offline

#7 2012-04-17 15:32:10

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Hello there, I'm the second Yii user SapporoGuy mentioned in the first post, so I thought I'd drop a line or two wink

Otomatic wrote:

I do not want a forum that would require to integrate into a "framework". I do not want any "framework" for my sites.
I want a forum lightweight, simple, without a whole bunch of stuff and stuff that used to almost anything, but who are there for what it is "fashionable"!

I think this quote illustrates that we haven't made it entirely clear what our goal is. Well, goals, actually. So let me try to explain:

First of all, we do not want FluxBB to become part of the Yii framework. Indeed this wouldn't be possible right now, since Yii per sē doesn't offer any CMS-like functionality. Much rather we weould like to rewrite FluxBB with Yii as the underlying framework. As it stands, a lot of great applications are being created. However, we're still missing an application that implements a usable  bb-style forum. In short, we're looking for a solution that is:

  • Lightweight

  • Extensible

  • Fast

  • Complete (i.e. there could be more features but the users will never miss out something substential)

Sounds familiar? That's pretty much what FluxBB resembles. But we need it with MVC and following OOP design principles. We also need it as both, a standalone software and as a module that can be integrated into other applications (which btw is why we would need the module part to be licensed at least under LGPL. But there's the other thread about that ...). From Yii's standpoint, modules are stripped-down applications, so it's not that far-fetched.

Now, what does Yii offer? Let's have a quick run-down of the FluxBB v2.0 Roadmap:

  • Database
    Yii has a powerful rdbms-agnostic query builder that sits on top of PHP's PDO. Support for MySQL, SQLite and PostreSQL is well tested and covered by PHPUnit tests. Taking advantage of that: Active Records!

  • Caching
    Yii comes with an extensive caching system that can cache simple queries, page fragments or even entire pages. The cache drivers support a variety of backends. Also, Yii is working great together with APC.

  • i18n
    All of the framework messages are already translated using Yii's built-in translation system. This can easily be extended into modules and/or applications.

  • Templates
    By default, templates in Yii are pure PHP files. However, there's a variety of alternative view renderers. E.g. for PRADO, Smarty and Twig. Above that, Yii supports themes out of the box. So user-selectable themes would be available almost instantly.

  • Authentication / Authorisation
    Authentication is left to each application/module. However, we have successfully integrated phpass in the past. Once a user has been authorised, a complex role-based access control system is available.

  • URL Routing
    All done with Yii.

There's a number of other benefits. For instance, Yii is shipping with gii, a quite convenient tool for code generation, increasing development speed drasticaly. Check the screencasts for more. More importantly, there is a great system for input validation!

Some random thoughts that I couldn't get in order yet:

  • Microformats
    SapporoGuy and I are both into this. Putting microformats in place is swiftly done by putting a few additional CSS classes into the right spots. Stante pede I'd say it were pretty easy to equip profile pages with hCards, which are also being picked up by Google and others. Other possible formats were hAtom and cite-rel for quotes. The overhead is quite small. If people don't like this, we could just put them into "enriched" themes.

  • BBCode Parsing
    Yii has nothing for this. I've still got a complex 5k loc parser that's creating a parse tree and can fix nesting orders. My current diea is to refit that into Yii and refactor the entire thing so it can be wrapped around PECL::bbcode.

    While we're at it: I'd like to propose an enhancement to the quote-tag. Instead of a generic string, the param should also be either a numeric id (being a post id) or a fully qualified url. This will make quoting other posts or even websites more convenient (by placing a link to them) and allow for the usage of the aforementioned cite-rel microformat.

  • Plugin Ideas

    • Stats
      Users *love* statistics. But they are expensive to generate, so moving this kind of functionality into a plugin might be an idea.

    • Dashboard
      Admin dashboard? Convenient. Individual dashboard for every user? Great. It might be an idea to have the statistics as a dashboard that can only be altered by administrators.

    • Link-, Ping- and Refback
      Currently only blogs have this functionality. But there's little reason why forums shouldn't feature this as well.

    • Messaging, Reputation System
      I'm not really fond of them. But having these as plugins might be key to get the current Yii forum replaced with a future version of FluxBB => Instant growth of the FluxBB userbase by +60k.

Franz wrote:

Laravel is the first one I've seen that seems possibly simple enough.

Yes, well ... Laravel is impressive. The tarball is less than half a megabyte while the latest release of Yii adds up to 5.2MB, expanding to ~50MB on the disk. But keep in mind: (a) Those microframeworks are mostly there because of some kind of mental challenge. They are hardly ever backed by a solid userbase. (b) Yii is really, really small. A lot of the framework is actually documentation. AFAIK Yii is phpDoc complete. There's also a lot of stuff for translation, including formatting options (the i18n folder of tha latest release is roughly 27MB in size). Also, Yii is following a "loaded when needed" approach, so you should never have all of this loaded at once.

Franz wrote:

But keep pushing us smile

Frankly, we will push you to nothing. We are not with Yii's marketing or sales department (if such a thing ever existed). We just see so many common goals with our project and FluxBB 2, it were ridiculous not to work together. We see many opportunities and advantages Yii would bring to FluxBB. Clearly, a lot of effort went into the 2.0 alpha, so we have missed the right point to bring Yii into the game, but we feel it's still not too late: While we could easily just go and create our own software, we really hope that FluxBB and Yii will find a way together. You know: the more, the merrier big_smile

Offline

#8 2012-04-17 16:10:37

heartcall
Member
From: Western SD
Registered: 2012-04-12
Posts: 85
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

If I may add... although not all that techy, but from a user perspective.

I like and simple... easy to use board system.  Back in the day I had a pretty decent Community of members... nothing all that great, but there were days when we would come close to 200 posts in one day.  Of course those days are behind me.

Recently I've decided to incorporate a forum system again... mainly because I have some friends who are FACEBOOKED out and desire a Community to hang out again... like what we had in the past.

I dunno if we'll ever get back to that level of usage again... but I am excited to have a place to once again focus on a Community instead of a monstrous FB styled place to connect. 

The way some message board systems are heading these days, it seems what they are attempting to do is compete with FB in a sense... maybe I am off, but it looks that way to me.  I don't want that!

FluxBB provides an easy to use format to talk and discuss things.  For that... I am thankful!


Life may not be the party we hoped for, but while we're here we should dance!!!

Offline

#9 2012-04-17 16:28:29

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Re: Yii framework + devs :: alternative path for Flux 2.0

Heartcall +1 I totally agree with you!

This thread is the geeky side of things smile Pounding out things that most users will never even bother worrying about!

Offline

#10 2012-04-17 16:33:33

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Well, we are in no way trying to compete with facebook. In fact, I feel that were the entirely wrong way to go: Facebook is not a forum and bb-style forums are no facebook substitute.

SapporoGuy already pointed out that we intend to provide a clean and intuitive UI. I might add some ajaxified controls, but it is my idea that all the core functionality remains intact with JavaScript being disabled.

Last edited by Da:Sourcerer (2012-04-17 16:35:38)

Offline

#11 2012-04-17 16:33:43

heartcall
Member
From: Western SD
Registered: 2012-04-12
Posts: 85
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Cool... keep us the good work then wink


Life may not be the party we hoped for, but while we're here we should dance!!!

Offline

#12 2012-04-18 09:30:42

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 5,876
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

I am not in the position to make a finite decision about this, but don't you think that the software could still be written in such a way that integration would still be fairly simple?

Why do we need all the overhead of a nun-custom framework?

This is how I envision it anyway.


fluxbb.de | develoPHP

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

Offline

#13 2012-04-18 10:47:13

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Re: Yii framework + devs :: alternative path for Flux 2.0

Simple answer would be try to fit in a restful API approach and then generate all the extra ajax and what not.
Ending up creating a lot of code that other people have done.

A framework, cuts down on time and provides you with tested solutions.

We are pushing Yii, because that is what we are familiar with.
I chose Yii for it's merits compared to other frameworks.

Offline

#14 2012-04-18 11:33:34

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Yes, you could. There's a history of integrating third party solutions into yii apps. But: This will severely lower acceptance in the Yii community as this approach will never feel "clean". Alone the fact that FluxBB will have to maintain its own db-abstraction with an additional database connection won't be tolerated by some. For what we have in mind, this might be a dealbreaker.

Last edited by Da:Sourcerer (2012-04-18 12:31:40)

Offline

#15 2012-04-18 12:29:26

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 5,876
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Hmm, good point. Let's wait for other opinions then (especially from Jamie).


fluxbb.de | develoPHP

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

Offline

#16 2012-04-23 20:26:37

Oldskool
Developer
From: Netherlands
Registered: 2008-12-28
Posts: 152
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

I'm not sure this would be the way to go. Don't get me wrong, I'm all for frameworks (I recently migrated the app I code on my daytime job to CakePHP to simplify and unify things), but only when they make sense.
Using a framework for a forum software that's supposed to be lightweight and simple without too much hassle really seems a little bit overkill to me.

A framework is easily 10-25MB and that's just the basic stuff. You still don't have any functioning application at that point. Doesn't seem very lightweight to me.

Furthermore, our community is very active in creating and maintaining mods for FluxBB. By developing on a framework, you force all of them to also go and use that framework (or at least require OOP mods that extend the framework). I'm afraid that this will really discourage many people with just 'basic' PHP knowledge to keep writing (simple) mods.

Add to that the fact that when using frameworks in public projects like this, you'll always have to stay current to the latest versions of the framework and are bound by their requirements. The requirements of FluxBB would then be at least equal to those of the framework, meaning we can no longer be flexible when it comes to support for PHP version, required PHP (and Apache) modules and such. We've always been pretty flexible with that to allow a large number of people, also those on older hardware or on machines not maintained by themselves, to still run FluxBB. That would become a lot harder.

So all in all, no I'm not a fan of frameworking Flux. It just doesn't fit here.

Last edited by Oldskool (2012-04-23 20:27:52)

Offline

#17 2012-04-24 09:44:04

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Oldskool wrote:

Using a framework for a forum software that's supposed to be lightweight and simple without too much hassle really seems a little bit overkill to me.

What if the framework is lightweight itself? wink

Speaking of OOP/MVC: I ported some legacy web applications to modern frameworks with template engines. It is my experience that they ended up with less lines of code. Always.

Oldskool wrote:

A framework is easily 10-25MB and that's just the basic stuff. You still don't have any functioning application at that point. Doesn't seem very lightweight to me.

True, there is little we can do about that. But keep in mind: A lot of that is made out of translation files and phpdoc. Also: Do not underestimate what the framework gives in turn. I recently managed to create a planet site complete with atgs and feeds in less than 10 hours. Raw application code: Far less than 100kb.

Oldskool wrote:

Furthermore, our community is very active in creating and maintaining mods for FluxBB. By developing on a framework, you force all of them to also go and use that framework (or at least require OOP mods that extend the framework). I'm afraid that this will really discourage many people with just 'basic' PHP knowledge to keep writing (simple) mods.

Not sure if that's a charge against OOP or the intellect of your modding community. In either case, I find it hard to take this serious hmm Your current modding system requires people to patch the core code of FluxBB. What we have in mind are classes extending a plugin class registering itself to several hooks. That's a lot cleaner and allows saner upgrade paths. Have a look at the way plugins in Habari work and you'll understand.

Oldskool wrote:

Add to that the fact that when using frameworks in public projects like this, you'll always have to stay current to the latest versions of the framework and are bound by their requirements. The requirements of FluxBB would then be at least equal to those of the framework, meaning we can no longer be flexible when it comes to support for PHP version, required PHP (and Apache) modules and such.

Er, not sure where you got these ideas. The minimum requirement for Yii atm is PHP v5.1.0, PDO and the reflection API. in fact, I think Yii could even do without PDO. One of the most popular Yii apps is chive, which aims to be a phpMyAdmin replacement. Bundled version of Yii: v1.1.1. That's 9 (!!!) releases away from the current framework version. I've got no doubt it will still work if you simply replaced that with the current version. Yii is maintained by people who now their stuff. And they are very carfeul not to introduce bc-breaking changes within minor releases. Also: Yii works very well on Apache, Microsoft IIS, nginx, Lighttpd and Cherokee. No additional modules required, pretty URLs are completely optional.

It is true that most of the apps created with Yii are going to be deployed on dedicated servers where installing another binary extension for PHP won't be an issue. But we've still got a heart for people sitting on shared webhosts. Yii's minimal requirements aren't an issue even for Debian boxes.

Oldskool wrote:

We've always been pretty flexible with that to allow a large number of people, also those on older hardware or on machines not maintained by themselves, to still run FluxBB. That would become a lot harder.

I tend to agree to some point. Boxes with ancient operating systems or outdated hardware will have a hard time running a Yii-based FluxBB. However, if you always want to carry those folks with you, you will lose a lot in terms of your ability to introduce innovations. This might sound a bit harsh, but it's just the way it is.

Offline

#18 2012-04-24 14:27:39

SapporoGuy
Member
Registered: 2011-05-29
Posts: 34

Re: Yii framework + devs :: alternative path for Flux 2.0

I'd also like to add in that there is a difference between users
And devs.

WP is dead simple for users, install, click, edit, presto! Instant site it seems.
Users don't care what powers there stuff as long as it works.

Devs are a more delicate issue. I just walked away from code that you have to edit core files, even though the code is OO and mvc! Pure insanity! Everything breaks because the main dev thought a new cool feature would be useful. Ughhhh! Security goes out the door because people don't want to upgrade and spend more time or money fixing issue that a x.y.z+1 release causes.

I do understand the concerns from a hosting point too, but then again if a host is unwilling to upgrade to php5.3 or even 5.2 there are bigger issues than worrying about a framework following proper release procedures.

I've gotten several Yii 1.1.3 apps to work on 1.1.10 without even an issue outside of my own stupidity in configuring my vhost or htaccess file properly.

As for the 20meg file hog. Well, the current trend is almost all companies say "hardware and space is cheap" ... Not a good reason but I don't see too many people using word 3.0 or sticking with notepad. Maybe a bad comparison but the idea is that a stable well thought out fully active community is a hard to argue against.

For devs: this is a much harder issue because they have to learn something new.
BUT, learning a object orientated programming on top of a mvc is actually a good thing. Lol, like eating spinach, it sucks until you realize that you glad you did!

Offline

#19 2012-04-24 20:26:48

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

I need to take down some ideas and thoughts, so excuse me for being my personal scratchpad. But feel free to comment smile

Engine Core

  • Install Routine
    We need this as an interactive wizard, no way around it. We cannot expect users to install and configure a copy of the software via raw PHP files. Current idea: Store them in application.runtime.config and include them in teh static config under application/config/main.php. If application.runtime.config isn't present, start the install routine. Also: have an option to upgrade an existing FluxBB installation or migrate from another engine (phpBB, MyBB, FUDforum, IPB).

    We would need to fetch configuration info for the DB connection (MySQL, SQLite, PostgreSQL), a caching backend (memcache, APC, XCache, WinCache), mail configuration (local sendmail interface or remote (S)SMTP server) and all necessary informations for an admin account. Also: Give an option for the innitial RBAC setup (open forum or closed community)

  • Basic Profiles
    A user should at least have a valid email-address. This will be the only required contact information as this is used for account validation. Adding additional contacts should be possible (ICQ, Jabber, AIM, MSN). Possibly equip profiles with hCards.

  • Core Messaging
    A forum has:

    • Categories consisting of

    • Boards consisting of

    • Threads consisting of

    • Posts

    Users can subscribe to threads and receive notifications via email (note: Perhaps per Jabber too?) when somebody replies to them. Optional: Let users opt-out of notifications. Subscriptions could double as bookmarks.

    Edits to posts should be held in an additional table, so we've got a full history on single posts. This will help us with more precise cache invalidations as well as take note of updates in the atom feed(s). Posts and edits should hold a NULLable uint(128) field to take down the originator's IP address in packed binary format (NULLable to comply with certain legislations privacy laws).

    Read thread tracking could be implemented by an additional relation between threads and users with a timestamp of the last visit. The timestamp can be compared to tha last update of a thread, so we have more accurate tracking on threads. (Yes, this table will rapidly grow in entries. But it will never be really large. The maximum number it could ever have is |Users| * |Threads| and as we really just take down a DATETIME and two uint(32)s, that will not be really large)

    Threads should be splitted and merged on demand.

  • User Management
    We need facilities for user creation, suspension, activation and password recovery. Users should be able to be sorted into usergroups for both, identification and rights management (by linking them into RBAC rules).
    Another point were renaming users (should be left to moderators and admins as this is likely to add confusion).

  • Plugins
    We need an infrastructure for non-invasive plugins. Current idea: Hook into controllers and models via a PluginBehavior. That behavior would then take advantage of the existing event hooks in Yii and poll a PluginRegistry for plugins that want to be loaded into the processing chain. We will need an abstract BasePlugin class and several interfaces for plugin classes. Plugins should at least bring a install() remove() and config() method. config() could take advantage of the form builder present in Yii.

    Also: Separate plugins into application.plugins (supplied and maintained by the devs) and application.runtime.plugins (community supplied plugins). This should allow us to distribute some quality plugins that can be used to enhance the core functionality by demand, maintain them through regular releases and let them serve as blueprints for community plugins.

  • Dashboards
    It's hard to implement this through a plugin, so it should go into the core. A dashboard consists of several freely placed dash widgets. A DashWidget will provide:

    • A number of prerequisites so the dashboard knows if it can be used,

    • an access rule, so we can limit usage of it,

    • a cache factory, so we can cache its content

    • a dataprovider for the content

    DashWidgets could be distributed the same way as plugins, opening another branch of community-supplied code.

    In addition to an admin dashboard, each user could have their own. An additional, public dashboard might be suitable for displaying statistics.

  • Ban Management
    In addition to marking users as suspended, we might need the ability to block specific IPs or even entire netblocks. This requires an additional table and a lookup prior to each controller action. This can be done via a filter. However, these lookups can be quite expensive, so we should cache them.

  • BBCode
    Hot topic. Most userland BBCode parsers are garbage that cannot be trusted to produce valid (X)HTML. PECL::bbcode exists, but it's a binary extension that might be unavailable to a lot of users on shared webhosts. We could take a junk parser and pass it through HTML Purifier (unsolved problem: Purifier is one hefty piece of software. Running this over every piece of parsed BBCode is expensive so we would need to cache the output. If we do that, we might litter the cache)

  • Feeds
    The entire forum, boards and threads should each have their own feeds. Atom has turned out to be much more suitable than RSS. We could write a FeedBehavior for this. Feed generation itself should happen through XMLWriter. It's simple enough to not bother using an external lib.

  • Themes
    We will need at least one mobile theme. The current theme can be reused, I think. About styles ... probably too. We would need to either create a new theme for each style or have styles applied to themes.

Must-Have Plugins

  • Reporting System
    This will only make sense on larger installations, so smaller forums should have the option to disable this. It would be unnecessary and possibly confusing.

  • Messaging System
    Often requested feature. But likewise, it only makes sense on larger installations. It should also have the option to apply some limits, so the stored messages won't grow too large.

Nice-to-Have Plugins

  • Linkback
    Let a plugin fetch all incoming pingbacks, trackbacks and refbacks. This would be fun to do in a forum, but it's also an entry point for spam, so we should think about countermeasures.

  • AtomPub
    A plugin that would take AtomPub requests to put new content into a forum would be pure genius.

  • File Attachments
    Not needed or desired on any forum but some would certainly have their time with it.

  • Wordfilter
    This is a policy thing and I wouldn't want to have that in the core ...

  • Flood- / Spamcontrol
    Implement policies like "You cannot post within 1 hour after registration" or "You cannot post links while having a postcount < 5". Might also take control of user's signatures: No links and/or images in signatures.

  • Polls
    Popular feature, should not be left unattended.

  • Soft Deletes
    Mark boards/threads/posts as deleted and move them into a virtual trashcan before permanently deleting them

Don't worry, I'm not done yet wink And yes, I am aware that current FluxBB has a some of these features.

Last edited by Da:Sourcerer (2012-04-24 21:03:10)

Offline

#20 2012-05-02 17:36:18

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

I don't want to sound impatient, but I find the lack of feedback a bit worrying. Please keep in mind that SapporoGuy and I are both investing our free time in this. Since we are reluctant to start any actual work without your consent, we're pretty much on hold.

Offline

#21 2012-05-03 10:32:10

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

Re: Yii framework + devs :: alternative path for Flux 2.0

Hi,
I'm still skeptical, even suspicious. I see absolutely not what it will be easier to "modders" and especially to single users.
Excuse me, but I feel this approach only as an advertisement for Yii and nothing else.
You spend an incredible energy; you write hundreds of lines to try to convince me that Yii is the future. This may be the future for Yii, but not for users of FluxBB.
A sentence of Henry Montherland, difficult to translate into English, summarizes very well your approach:
« Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. »
« Today, the ideal of progress is replaced by the ideal of innovation: it's not better either, it's just that it is new, even if it's worse than before and this obviously. »


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

#22 2012-05-03 11:14:15

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Otomatic wrote:

Excuse me, but I feel this approach only as an advertisement for Yii and nothing else.

I'm incredibly sorry to hear that. I tried to explain how both, the Yii and the FluxBB community, could profit from a colaboration, while being as balanced as possible. If it just felt like advertising for Yii to you (and possibly others), I have clearly failed.

All I've got left to offer would be to write a rapid prototype and take down how long it took me to write that.

Last edited by Da:Sourcerer (2012-05-03 11:14:31)

Offline

#23 2012-05-03 15:49:38

François
Member
From: Lyon (France)
Registered: 2009-09-01
Posts: 197
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

Da:Sourcerer wrote:

Please keep in mind that SapporoGuy and I are both investing our free time in this.

So do the developpers of FluxBB. They have two released to prepare and not necessarily the time to take such a decision like this one wink.


Sorry for my English, I'm French

Offline

#24 2012-05-03 16:10:01

Da:Sourcerer
Member
Registered: 2012-04-14
Posts: 15
Website

Re: Yii framework + devs :: alternative path for Flux 2.0

I am fully aware of that. But we're almost three weeks in since SapporoGuy started this thread. It's just a matter of politeness, M'kay? wink

Offline

#25 2012-05-03 23:51:43

arw
Member
Registered: 2012-03-20
Posts: 117

Re: Yii framework + devs :: alternative path for Flux 2.0

Da:Sourcerer wrote:

All I've got left to offer would be to write a rapid prototype and take down how long it took me to write that.

it would probably be simpler to give code of an actual apps using yii, for exemple there is the blog system :

- demo : http://www.yiiframework.com/demos/blog/
- code : https://github.com/yiisoft/yii/tree/master/demos/blog


and otherway if we watch licence there is smf2 ( in bsd ) and mybb ( in lgpl ), i don't use them but even if you want something more lightweight like fluxbb, you could maybe remove chunk of code not wanted ( and mybb next version would be on yii, so wouldn't it be the simple way to get good system forum for yii framework ? )

Offline

Board footer

Powered by FluxBB 1.5.7