Thread

Agreed. Recoding the framework should be left for projects who’s aim is to recode the framework. There are plenty of those around already. Tweaking and improving should be the aim of the CodeIgniter Branch or it will just be two totally different frameworks with the same name that are totally incompatible

By any chance, are you a mainframe developer? Still running Windows 98? Of course not, but I’m trying to make a point. Stability is great, but CI has been stable for 4 years. At some point, all software requires a rewrite to stay relevant.

DChill, you are asking me to give up on CI. I have 4 years invested in it. I must use it for EE development. But most importantly, I don’t like to give up. 

I don’t own a torch or a pitchfork. If I don’t get my way, nobody will lose a head.

On the contrary, it seems to me that you are an assertive member of the community with ideas to share and the will to contribute - I don’t want you to give up at all. I am just trying to understand the direction you’re moving in, and figure out if it’s truly good for the community at large.

I see an important distinction between giving up and focusing energy in a direction that can truly bring about change. While the fork might seem productive to you now, I (as I said) am not convinced that it would pan out in the bigger picture. Then again, I might not fully understand your vision of the future, either.

You previously mentioned EllisLabs’ best interests and likely courses of action, and I think your basic point was correct. They use this codebase to run their enterprise business, and as such they have a vested interest in its continued usability for their internal purposes. Of course, without that arrangement, CI would not be free to the rest of us, so let’s not look a gift horse in the mouth. By the same token, enhanced performance and usability would also be in the company’s best interest, as long as it didn’t incur changes in their dependent code extensive enough to be prohibitively expensive.

What I perceive here is that you have already given up on Ellis’ willingness to make the changes you want to see, in favor of fighting for your own sandbox where you can do it yourself. I wouldn’t be so sure that they won’t adopt more changes than you are giving credit for. I think this is part of their reasoning behind the Community Branch - it could be a proving ground where they can see the community’s ideas worked out in actual code that they can incorporate into the official releases as they see fit. Sure, radical rewrites aren’t likely to be taken in, but that doesn’t mean core code can’t be adapted and enhanced to make justified improvements.

If I’m off track, here, let me know - I’m only interested in pursuing the best future for CI and the community, and I’m not a certified mind reader. I would just hate to see Ellis decide there’s no point in opening up the Community Branch because the community got up in arms about a fork.

Many of the ideas you listed were discussed when Phil Sturgeon setup that chat session last week, ideas #1-4 specifically.

Yep, #1 was deleted from his document

It was removed pending discussion, as nobody actually detailed how auto-loading would work. What’s are your ideas for the implementation?

In my perfect world, I’d like php namespaces combined with php 5.3’s neat class_alias() function to enable transparent class extensions with a cascading file system. But there are many different implementation possibilites, and I’d welcome a debate of several proposals.

I’m sure you know this, but basically autoloaders require namespaces or a naming convention to work. The PEAR/Zend naming convention of Dir_Dir_Class for class names is almost standard. Namespaces are cleaner: dir/dir/Class.

Autoloading could even work for CI as-is. CI class names are now prefixed with the naming convention “CI_”. So, within the autoloader, if a class name is prefixed with CI simply call the CI Loader class’ “_ci_load_class()” method.

DChill, I could be wrong about what I perceived as Ellislab’s intention for their community branch. I would love to be wrong.

Agreed. Recoding the framework should be left for projects who’s aim is to recode the framework. There are plenty of those around already. Tweaking and improving should be the aim of the CodeIgniter Branch or it will just be two totally different frameworks with the same name that are totally incompatible

By any chance, are you a mainframe developer? Still running Windows 98? Of course not, but I’m trying to make a point. Stability is great, but CI has been stable for 4 years. At some point, all software requires a rewrite to stay relevant.

That is a good point, but consider this.

EllisLab have been good enough to say “Ok, if you wan’t to make improvements go ahead. We’ll make this branch so everybody can contribute ideas and suggestions to the same place and we’ll take those that we see as a benefit to our product”.

This is more than has been done before as in the past people have just got in a huff and made their own forks. Admittedly that is slightly what Fuel started as, and is exactly how Kohana started.

The problem is if the community start drastically changing everything then how can EllisLab be expected to merge it? It would just become a totally uncompatible fork that might as well be third-party without a “EllisLab” badge, which you can do right now (and many are).

If we change everything, autoload everything, recode all the libraries, make it all HMVC, etc then they would have to totally recode ExpressionEngine. You know as well as I do that would be a nightmare :gulp:

I don’t believe any drastic structural change is needed to improve CodeIgniter. We can start small with useful, iterative improvements and see where it goes. This is a great change for CodeIgniter, but I really do think expectations need to start low and reasonable for this to work out.

Not being contentious, I’m trying to explain my view on this discussion. Please do not respond with negativity or assume I am trying to control anything :down:. That said I do know several of the other Deputies feel similarly.