Community Feature Requests

[eluser]Phil Sturgeon[/eluser]
A few of the IRC guys got together and had a chat about what features we'd like to see in the Community Branch.

http://typewith.me/ep/pad/view/8PCEoGEJV1/rev.3296

We don't know anything much about who will be the Code Deputy's, but this list of suggestions will hopefully be useful to them.

I've linked to the most recent version I checked. It's open to edit so may get more or less relevant and spam filled over time.

Discuss!

[eluser]Bastian Heist[/eluser]
Hey, typewith.me ignored me!
However, as I said, I'd really love to see an official auth library. I think most sites today need something like this, and it'd spare all of us the pain of writing something this sensible ourselves.
I'd also like to see helpers as static classes, and a general cleanup in tzhe helper section, as the naming sometimes is really confusing.

[eluser]smilie[/eluser]
Just added my $0.02 in the doc...

Cheers,
Smilie

[eluser]Derek Jones[/eluser]
Nice initiative, Phil!

[eluser]WanWizard[/eluser]
my €0.02 added as well. I'll check my pocket for more change later...

[eluser]Phil Sturgeon[/eluser]
Thanks for the additions Harro but I think a few might be a bit big for now? I was trying to keep suggestions fairly small as nobody wants to re-write their entire app.

For autoload how would you see that working? It makes sense for helpers, but how would it work with models/libraries being added to $this-> ?

The session library would be amazing if it was a driver and could be implemented without any code-changes required. Do you have a fix for the bug you mention?

We need better namespace support than this. If you have a highly modular environment, you don't always control the naming of classes and methods in individual modules, also if you build an application with lots of reusable modules, name collisions are bound to happen, even with prefixes. And often, renaming is not an option, this has an impact on reuse and portability.

With this I know exactly what you mean, but this is a problem that already exists in CodeIgniter and would not be worsened with controller prefixes. For changes to be accepted they'd need to be small, easy to update with little/no effect on existing code.

Throwing in namespace support is going to be way out of scope for this I'd have thought. I'm not in control or in charge of any decisions like that, I'm just pre-empting Ellis responses to save us all having unused code sitting in forks. :lol:

[eluser]WanWizard[/eluser]
Perhaps, or should I say Probably.

I read the title of this post as "feature requests", not as "what is possible now and without making waves" .

I fully understand that some of these items on my wishlist are not for tommorow, and probably not even for the day after. But after all the OSS projects I've work on, I've learned that a feature, issue, bug, etc not registered is one forgotten.
One needs this kind of input as well, to be able to work on some sort of roadmap, which in turn is absolutely vital to make sure you arrive at the destination you want (and not fall into the Kohana trap by making radical direction changes).

The session 'bug' can't be easily fixed without rewriting quite a bit of code. I've posted a drop-in replacement with a fix (i.e. hack) some weeks ago, but I'm not happy with it. I've already implemented session drivers for Fuel, I can easily port the idea (the code will be different) to CI, I think it should be possible to even maintain method compatibility, but I'll have to dive into it. Before that, the idea of drivers that currently exists in CI-tip needs to be reviewed, as it's quite basic now, and lacks some important features (like I can't drop a library in my application to add a new driver, I need to modify system code).

With better namespace support, I didn't mean 'introduce PHP namespaces', because that doesn't solve the problem at all (at the moment).

Consider the following (taking an environment you know as example: Pyro): you publish this CMS with modular capabilities. Someone decides to write a Pyro module, and he calls it 'RandomName'. In parallel, someone else also develops a module, and guess what, he calls it 'RandomName' as well. With namespaces, chances are they would have picked the same name for that as well. Or the module name is different, but they both contain a controller called 'Controller_Forum'. And so on. Not a problem with routing to modules, big problem if you use modules to drive widgets.

Hardcoded names also make it impossible to install module code twice (there are situations where you would need that), without doing a search-and-replace through one of them, creating a maintenance problem, because now you no longer have one codebase.

Very complicated to solve, will require major changes, and will not be for today. But it could be a roadmap target for 3.0 for example...

[eluser]Rick Jolly[/eluser]
The title of this topic should be "Roadmap for Phil's Fork".

Seriously Phil, this isn't your project. Stop making the rules, and stop deleting contributions.

[eluser]Phil Sturgeon[/eluser]
I've deleted a few suggestions that we agreed has no place, and a few others that I know for a fact won't go in. I've discussed the features with Pascal too.

This is nothing to do with just what I want, I'm making sure suggestions are well thought through and written properly. If un-managed that list would be the usual "can I haz youtube?" junk that feature requests usually end up as.

The only rules I'm making up are how to help me make a good document of suggestions. This entire thing may or may not be ignored, but I want to give it a fighting chance by not filling it with a hundred features that will never happen.

[eluser]Rick Jolly[/eluser]
Phil, if you "know for a fact" what will be included, then why start this discussion?

Typewith.me, the feature request format you chose, does not facilitate an open community discussion. Something like uservoice allows the most popular ideas to rise to the top, not necessarily Phil's or even Ellislab's ideas. Uservoice also allows healthy debate.

Now, the most glaring problem with this discussion is the purpose. IMO, the focus of the fork shouldn't be features, the focus should be architecture. The only significant problem with CI is age. The philosophy is right on the mark - simple, small, and thoroughly documented. Apply that philosophy using modern practices with brilliant leaders and programmers and you have a winner.