Roadmap..?

[Jelmer Schreuder]

Hey all,

I'm not all that happy with Dan's roadmap from last night, and I have 2 reasons for that: the first being that it shows us focussing on the wrong things and the second is the content of it. This should be one of the things we discuss on a list like this one before announcing through twitter. It's not that I don't want it public (this is), but the Twitter account should announce the official stuff - discussion should go here.

My first problem is that our focus right now should be on stabelizing the framework, getting out the bugs and seeing what kind of consistency mistakes are still left. And of course Unit tests.

We want to be a serious framework to be used by serious developers, and not the next framework that is hated for its wildly changing API that seems to change on a whim. We made some choices for 1.0, and for good or bad we should be mostly stuck with them untill we go for 2.0. But we have yet some road to travel for 1.0, and that distance is not to be underestemated. After that 1.01 bugfix release and 1.1 for some serious (mostly API consistent) improvements should be the focus. While 2.0 stuff is nice to fantasize about, it should not yet be a serious topic for us if we take Fuel's reliability serious.

For others to take us as a reliable and serious framework we need to stabelize and not keep playing with the API untill we have a stable 1.0, and preferably only after 1.1.

Onto my second problem: the contents. Let me start of positive: I think the config drivers and using the autoloader for non-class loads as well are good ideas. And both should be fine for a 1.1 and not break anything. And the Cascading class idea sounds interesting.

- Allow automatic environmental variable usage. This would be like Symfony2 allows. You would use something like this as your config value: %db.pass% This would then be replaced with the value of $_SERVER['FUEL_DB_PASS'] which would be set in .htaccess or your servers config.

I hate this, looks far too much like magic to me. Why are we adding string parsing when people could just type the variable name? What's the real upside of '%db.pass%' over $_SERVER['FUEL_DB_PASS']? It just takes a bit of extra resources and hides the real PHP behind some magic.

- Become compliant with PSR-0. This basically means that file names are the same case as Class names.

This is real 2.0 stuff to even be considered, and shouldn't be even supported untill 2.0. But I dislike it and I always have, I did this for one of my projects and have regretted it ever since. It's not prettier, it is just asking for mistakes, and it makes the filename superior the the classname (because for autoloading the filename's casing is more important than the class's). The Autoloader you (Dan) wrote is pretty great and very efficient, an unknown namespace is quickly abandoned and can be handled by any PSR-0 compatible autoloader someone wants to add on top of ours with very little overhead.

Is there an actual upside to this, other than supporting a standard we've never cared about before and support for which can already be added easily.

- Provide backwards compatibility (but throw deprecated warning in development) for 2 versions.

No we shouldn't, those double filesystem checks add overhead that's really unnecessary and encourages bad programming. If we do this change it should be a 2.0 change and be a non-backwards compatible change done at once. But as I mentioned I'm very much against.

- Go fully namespaced (people will just need to learn).

I'm ambivalent on this, but of course this is a 2.0 consideration as well. If we do we shouldn't go back to aliassing everything, if we do it it should be done by having people "use"/import all classes from some central namespace. That is a good-practice in my book anyway because it forces you to be aware of dependencies.

It does however get rid of the current simplicity and I'm not yet sure if there are any real upsides to it. Isn't it just sacrificing simplicity for implementational awesomeness, something we've been very critical of Symfony2 for.

- Changes to the Router

I'm not sure if what I see there is actually really more OOP or flexible than the current system. I really like adding Route objects for each route, and because I can create my own Route extensions it offers some awesome flexibility. Having said that I don't think the current system is perfect, but I do think it's more on the right track than the proposal I see on the Github wiki.

Also I kinda dislike the config through closure, it doesn't really add anything over this:

$router = Fuel\Core\Routing\Router::init();

$router->add('base', '/', 'welcome#index');

But again, with the exception of the server variables, all these points I disliked are stuff for 2.0 and not for 1.0 or 1.1. And they would completely change Fuel while I'm not yet sure if they really improve anything from a practical point of view, it maybe more awesome implementationally but that's a weird trade-off for us.

Now I'll write a proposal for better Exceptions in Fuel you guys can trample into the ground next... ;-)

- Jelmer

[Dan Horrigan]

Nothing in this was concrete, more of a mind dump of ideas.  Let me go through some of your concerns.

- Allow automatic environmental variable usage

This would mainly be used for when you are using something other than PHP for your config.  For instance...if you store your config in XML or YAML, you don't have access to the $_SERVER array.

- PSR-0 Compliance

The idea here is to stick to standards.  There is no reason we can't.  People should be using the correct case for class names anyway.  This will do nothing but help people in the long run, no more going through and changing file names when using 3rd party components from other places like Zend or Symfony.

This is something I am not going to budge on.  It is going to happen...just not sure which version.

- Backwards Compat

I agree that this will add considerable overhead...but only if you don't comply with the new way of doing it.  Even at that, it will throw a warning when you do it wrong, so you will typically want to clear up warnings, so if  you do that...no added overhead.

- Changes to Router

The current system sucks...plain and simple.  To add the functionality it needs to be great would require a huge complex array, which people (and I) hate.  The idea to make it a closure is that it keeps the global namespace clean.  Ya, you could do what you suggested, but then you have a $router variable floating around that could interfere with things.

Overall I think it is important to note that these are just ideas, many of which will have to wait until v2.0.

I will also say that I know there are a LOT of things we can improve with the current API, and we will do that too, these are just some ideas I wanted on "paper."  Frankly many of these should have been done in 1.0, but I was strong-armed by people complaining it would confuse people (namely, namespaces).

Dan

P.S. Look forward to your Exceptions proposal :P

[Jelmer Schreuder]

About the $_SERVER var config: ok, that I get. Though it shouldn't be in the PHP driver then.

I think it would be good to categorize those ideas by which version they're to be expected. As I said I think that any big change to autoloading or router should go into 2.0 because people starting to use Fuel should be able to count on us not requiring them to do any massive rewrites untill 2.0, or really anything like a rewrite being more than a find-replace. If we're not clear in our communication about this people will get that feel they got with other frameworks that the base they're using will be supported for a month and then dropped for some new ideas which require major rewrites.

(btw making a big change and requiring major added overhead for the "old" way is also bad, which is why both should be imidiate changes for a 2.0 - of course announced months ahead of time)

The power of the current router really is in the objects, I currently have 2 additional router objects setup which do alternative routing in between the normal routing. I'd call that pretty complex and the array contains just 8 keys. I'd hate it if that were dropped.

The closure thing isn't a big thing, but one stray variable in global could easily be unset by the class loading the routing config.

And of course there's some things wrong with 1.0, we're not perfect and we'll make mistakes. But reliability and stability should be major factors that sometimes supersede our quest for perfection, some things will have to wait untill the next major version as much as we may grow to hate them.

But most important of all, we need a final 1.0 version that is stable and can be relied upon. Until we're at that point we're still really nowhere as a serious player. And while I do think it's important to plan for the future, that should be the focus for the next couple of weeks.

Also we might want to start finalizing a plan for what will be in RC3, release that asap and then put all our efforts in Unit Tests. I'll be honest, my time is very limited the next month and a half or so, but I'll keep bugfixing the Orm and try to get some unit tests done.

Jelmer