ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
XPath expert needed
In the PHPCR implementation using Doctrine DBAL we support search queries by converting the SQL2/QOM statements into XPath queries that we run on the XML stored in an RDBMS. Sounds insane, yes .. but it works pretty well .. obviously will not scale very well .. but it works for smaller data sets and there will be ways to improve performance later. In terms of functionality we have everything working quite well including JOIN support that was added recently.
What is needed to REST in Symfony2
I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed. The following is not an exhaustive unordered list and also not detailed enough but just something to illustrate where I feel there is still work left:
Good design is no excuse for wasting time
Symfony 1.x I would put into a category of frameworks focused on RAD, aka rapid application development. There are many other frameworks I would put into this category like CakePHP, Yii, CodeIgniter. All of these frameworks have their roots in the pre 5.3 days of PHP. I say this mostly because there has been a considerable shift in development methodology since then towards more decoupling and application of design patterns. As such these older RAD frameworks to me cut corners to be able to focus on the use cases they wanted to focus on. Now this is a quite legitimate approach, we all know that in order to make a solution truly generic it takes a considerable increase in effort and complexity. So focusing on 80% of what web developers need to do on a daily basis makes sense. This is mostly achieved by providing either base classes or the ability to use configuration files and conventions to reduce the amount of code needed to achieve functionality. However these frameworks tend to become quite painful when dealing with those other 20%. At that point they can actually become a hinderance and so you start to loose some of the benefits you gained for the 80% you worked on before. With Symfony2 we took a different approach. I would not call it a rapid application development framework. All it really does is add some more high level abstractions but it stays short of providing an out of the box solution. You still need to write the code and that code tend to be very explicit.
Where have all the core devs gone?
Symfony2 is without a doubt a very lively open source project. No small part thanks to Github, there is a flurry of tickets and more importantly pull requests coming in daily with dozens merged every week. These changes cover everything from small typos, to bigger refactorings, new test cases, documentation, performance optimizations. What even more positively stunning is that while there are a bunch of "usual suspects" the bulk of all of this comes from people that just submit the occasional change. Which means we have managed to make the community very inviting for new contributors. Something many other open source projects struggle with. So in a way one could say all is well. However I think its also important to define a direction for a project as a whole. I guess at a high level we are fine there too. We rarely have fundamental issues with determining what should go into Symfony2 and what should not. But what I feel is severely lacking is a prioritization and focus what should be happening within the next few months.
On predictable PHP release cycles
There is currently a vote going on to include Zends Optimizer+ opcode cache into PHP core. I am very happy with finally adding an opcode cache to the core distribution if only because it then forces to actually ensure that there is a working opcode cache together with every new release. What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages. First and foremost it will ensure that developers that propose a new feature will have a better idea of when their feature will be part of a release. This can encourage developers to actually bother with sharing code and it also prevents developers from getting disgruntled if their feature is deemed not yet ready for the upcoming release or even more importantly prevents half baked solutions from being pushed in just to prevent an unknown further wait time. Furthermore it makes it easier for PHP end users, especially larger frameworks and application maintainers, to plan their releases. Finally it poses the chance that distributions will better schedule the freeze time for PHP versions, rather than the current rather random choice they tend to do.