[dev] Horde as a framework

Gunnar Wrobel wrobel at horde.org
Tue Nov 1 07:29:23 UTC 2011


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.

But this thread really belongs to dev at lists.horde.org ;)

Cheers,

Gunnar

>
> mike
>
> -- 
> mike
>
> The Horde Project (www.horde.org)
> mrubinsk at horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de




More information about the dev mailing list