[dev] Horde as a framework

[Luis Felipe Marzagao]

Em 02/11/11 11:27, Jan Schneider escreveu:
>
> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>
>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> http://fabien.potencier.org/article/49/what-is-symfony2
>>>>
>>>> Good post and impressive list. This is where I think we lag behind 
>>>> as a framework, and where we have an opportunity to either leverage 
>>>> our own components - which are great, but which I personally have 
>>>> less time to work on these days - or to start using some of the 
>>>> symfony/zend/whatever components to replace our own and move 
>>>> faster. Obviously we used to leverage more PEAR libs and there were 
>>>> challenges to that, but maybe things have changed?
>>>>
>>>> Or maybe not. Mostly throwing this out for discussion.
>>>
>>> Personally, I would rather not start using another framework's 
>>> components unless there was a *really* good reason.
>>
>> I feel there are often many good reasons for borrowing from others :)
>>
>>> At least not for any type of major functionality. It's not so much 
>>> about NIH for me, but more about control. I like the fact that we 
>>> are using less and less PEAR libs.
>>
>> PEAR is a different thing. Most PEAR libraries are coded for PHP4 and 
>> remained on that level. It is quite hard to integrate stuff like that 
>> into a modern component based PHP framework. Using stuff from another 
>> component based PHP framework is a different matter. Both Symfony 2 
>> and Zend improved significantly in that area during this year. As did 
>> Horde with Horde 4.
>>
>>> While it *does* increase our workload a bit (more libraries to 
>>> maintain for one thing),
>>
>> This is not only about workload on our side but also about the 
>> progress on the other side. If we fork we are cut off from any 
>> advances the other side integrates into the code base. This may 
>> easily turn out to be the major problem of forking.
>>
>>> it gives us *way* more flexibility and control. ... and while it 
>>> might not always turn out this way, it should translate into less 
>>> time to work a bug/issue (no headaches with getting upstream to even 
>>> ack your question/bug report/patch etc...)
>>
>> I agree that working with upstream can be painful. Forking is the 
>> better alternative if working with upstream is a real problem. But I 
>> assume we only worked with PEAR so far. We never tried Zend or 
>> Symfony. Both communities are quite active.
>>
>>>
>>> Also, IMO, if we are going to continue to try to push Horde as not 
>>> just a groupware stack, but also a PHP framework, I'm not sure 
>>> borrowing another framework's libraries for any major functionality 
>>> would send the right signal.
>>
>> Quite the contrary. By showing we can *integrate* with other 
>> frameworks I believe it demonstrates that we are indeed a component 
>> based framework - not some monolithic blob. The integration of 
>> different component frameworks has been a hot topic during the second 
>> half of this year. People are interested in using the best there is - 
>> without looking at whether it is labelled "Zend", "Symnfony", or 
>> "Horde".
>>
>>> We may not have the same number of libraries, but those that we *do* 
>>> have are both extremely well thought out and designed to our own 
>>> high standards ... at least that's the hope ;)
>>
>> Every framework has its strength and weaknesses - and only limited 
>> manpower. Why not accept that fact and make the best of it? We have 
>> some very good components, yes - lets publish how to use those and 
>> how to integrate them with Symfony 2 or Zend.
>>
Let me hijack this discussion to give some input from the viewpoint of a 
completely beginner PHP developer and also a Horde code consumer. I 
think whatever the solution is (maintain its own components or borrow 
some of them elsewhere), the key element for growing and increasing the 
community is 'documentation' (at least for newcomers). When I looked up 
for frameworks as yii or symfony, what has caught my attention was the 
documentation (and even screencasts) available (for example: 
http://www.yiiframework.com/doc/guide/) and, thus, how easy it was to 
begin working with them, even if you know little about PHP, patterns or 
frameworks. The same thing is not true for Horde. Of course you can see 
it´s an awesome framework and once you catch the grasp of it, it´s 
really great and helpful, but if you´re a newcomer, you have to spend 
hours looking at code and trying to figure out what does what, sometimes 
without success. So the feeling is 'Horde is for pros'. The 
documentation on installing the groupware modules is great, but it would 
be greater if there was abundant documentation on developing with Horde. 
I think that is the main reason why, regardless of whether Horde has its 
own components or not, the horde community isn´t bigger. In fact, it 
looks like a miracle the entire project being maintained by few 
developers and I can imagine the massive work and amount of personal 
time each one of you has to endure in order to keep things working. 
Which may be the reason why there´s no time to spend on documentation. 
One thing leads to another. All of this to say publishing, creating 
examples and teaching how to work (develop) with Horde is, maybe, imho, 
the greatest way to improve Horde, make it popular, and get more help 
from the community, which could, in turn, ease your work.

Luis Felipe