This is a blog of current Qcodo and Qcodo website development activities. Official Qcodo announcements will also be posted here.
It looks like most of the changes from the most recent development release are stable. There are a few small, additional changes since then which are all nominal fixes and aren't a big deal -- so I've gone ahead and packaged everything up into our next stable release: Qcodo v0.4.22.
Please view the Changelog for all the details.
And as always, please feel free to post with any questions or issues. Thanks!
And just a quick follow-up to let you know that the Examples site and the main website have both been updated to the most recent v0.4.22 stable release of Qcodo.
Please post if you see / encounter any issues. Thanks!
Thanks Mike !!
I don't remember if you wrote about a roadmap - what would you put in versions 0.5, 0.7, and of course Version 1 ? (in other terms: what's missing now ?)
A roadmap was put up on the Qcodo Wiki by a couple of other folks in the community a while back, but I think it's a bit outdated. There are a couple of items in there that I agree with (e.g. moving outdated items into QPMs, etc.)
However, I disagree with the concept of version numbering, and that “1.0” means stable. For 5 years now, we have had a concept of both development releases and stable releases, and each release is clearly marked as one or the other. Just because the version number starts with a “0.” instead of a “1.” or “15.” or whatever shouldn't really mean anything. With over a quarter million downloads over the past 5 years, and over 100 million page views per month, I think the Qcodo Framework has shown its stability well enough. =)
I am okay keeping with the set of version numbering... in short, when we introduce a significant number of enhancements and features which will cause at least a moderate amount of breaking of BC, then at that point, we'll bump up to 0.5.x. But between now and then, with all the incremental releases we've got going, I'm okay moving to 0.4.23, .24, .25, etc.
Personally, the main thing I am working on is the integration with jQuery. However, since the goal is to not have any BC breaks after the move, I'm not entirely sure if we'll be moving to 0.5.x for the first release of it, or just keep with the 0.4.x branch. My hunch is that we'll jump to 0.5.x since it's significant enough of a change... but I welcome any feedback on that matter.
Beyond that, the only other thing I'd be interested in doing is switching over the codegen engine to use the PHP Output Buffer, which would then alleviate us from needing to maintain the Qcodo templating language for the codegen engine. I've already got a set of templates I've wanted to add as a QPM package for iOS developers (specifically giving you qcodo-orm functionality within your SQLite-backed iOS app, all in native Objective-C)... but it's a really messy set of templates since it's built on top of the current qcodo codegen templating engine. I believe if we can move to output buffering, then it will spur other devs to more easily/quickly post and share their own codegen templates and tweaks.
There are also some ideas with regards to restructuring QDataGrid and QDataRepeater and getting rid of eval (again, utilizing the output buffer as well). And if we can clean up all of our uses of eval(), then we can begin to look at offering HipHop compatibility for Qcodo, which I believe would be a very big win from a performance standpoint.
Anyway, these are a few of the “big ticket” items I have in mind. Along with that, of course, is all of the smaller things, additions, fixes, etc. that people have been coming with all throughout.
It's very interesting to know the priorities you have in mind for Qcodo.
Regarding HipHop, my opinion is that it could be put in low priority, as currently it's more a “trendy” novelty than a full-reliable solution for any development. It implies not only getting rid of eval(), but also getting rid of any database driver other than the old MySQL (not MSSQL, not Oracle... not even MySQLi) and some beautiful features as “PATH_INFO”. Also, the HPHP performance boost is not noticeable when making heavy use of system calls or database operations. HipHop gives the impression of being thought for heavy calculus iterations and not for generating web pages, as it has a VERY poor performance in simple string operations compared to PHP itself. And also important, there's a considerable amount of compatibility issues, some of them being fatal to Qcodo (as __get() magic function not working nested, due to performance impact).
In my humble opinion, it can be a heavy but futile effort to try to support HipHop for any non-particular web development, as it means supporting a PHP independent (and buggy) implementation that will always go BEHIND the official one in terms of reliability and features. All in all, half of the HPHP boost can be achieved by simply using APC with the official PHP implementation.
- HipHop unimplemented functions and features
- HipHop positive benchmarks
- HipHop negative benchmarks
- HipHop vs APC
- HipHop issues, 1, 2, 3
Fernando... thanks for the links and insight with HipHop. I'll be honest, while it's always been on the back of my mind, it hasn't been something that I've researched thoroughly.
I should and would have to probably spend some more time looking into it more closely before committing to any sort of effort with regards to HipHop.
Thanks again for your insight.
Thanks to you for the ongoing work. I'd really like to participate more actively in Qcodo's development, but currently that's not possible.