First I think it's worth pointing out that the kohana docs are continuing to progress and that they are very open to documentation input from the developer community and actively encourage users to fork their git repo and re-submit contributions. Rob Knight commented on the Paul Roke usability blog last year that this is a major shortcoming in the framework. I think this gap is just beginning to close. With a handful of dedicated community contributors combined with the straightforward factual approach to documentation, that current gap could well become one of Kohana's key strengths in the crowded web framework landscape.
I also think it's important to capture the fundamental simplicity of Kohana's proposal. The platform does not perform code generation and this is _not_ a shortfall, or a feature gap. Anybody who cares an ounce about what happens under the hood of their web-serving infrastructure is likely to shudder at the thought of code generation. Even more so if that code introduces blocking behaviours (SQL statements being a prime case in point) to the request cycle. I feel that the underpinnings of a web platform should start out with a set of very simple, crisp platform primitives, which enable hand-crafting of business logic or specific data-access operations through extensions/implementations of fairly abstract base classes within the framework's subsystem. My early impressions are that Kohana are as close to this ideal as I have seen so far..
My key concern with Kohana is its filesystem-override approach. Whilst this presents an obvious means of hierarchical decision making, and perhaps a logical home for a localization/specialization architecture, the potential for scaling issues is a real threat - Take six or seven dimensions of specialization - and extend that to 30 markets, or perhaps 50 'locales' and you suddenly have a very deep, monolithic filesystem which can bring new problems into a web architecture - Namely, providing a means of navigation to manage the _right_ file for a particular fragment, or perhaps debugging a production issue and having to cycle through multiple layers of overrides to root-cause the problem. Or what if you need to add a new dimension to that hierarchy?
There are various approaches to solving this one. When I worked at Yahoo!, we eventually moved away from the mass-file system specialization hierarchies towards a resource-bundle approach. We also spliced translation management out of the web architecture to allow a separate offline system to handle translations. The localization effort was then driven entirely through configuration, which was shipped around in a non-FS, platform agnotisc structured format (I am intentionally evading a full description of the architecture). Needless to say, the outcome was a localization solution where the 'translation' problem was taken away from the web infrastructure, the i18n issues were handled within the core platform, which just left 'product configuration' and 'l10n' which were managed through structured configuration bundles which were loaded into the platform during bootstrap and remained in-memory from that point on.
I am tinkering with Kohana at the moment and will continue to think about other means of tackling some of these tough, re-occurring web platform issues.
christo
