[dev] Horde as a framework

[Gunnar Wrobel]

Quoting Jan Schneider <jan at horde.org>:

> 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.
>>
>> But this thread really belongs to dev at lists.horde.org ;)
>
> I moved it there.
>
> I'm with Michael. I think we 4 kind of framework packages in Horde:
> - Packages that don't exist (to that extent) anywhere else (SyncMl,  
> Date_Parser, Imap_Client, Vfs)
> - Very simple, yet common packages (Url, Util, Serialize)
> - Packages forked because the upstream situation/quality was  
> unacceptable (ActiveSync, Ldap)
> - Packages that have duplicate functionality in other frameworks  
> (Db, View, Yaml, Log)
>
> I think the first 3 categories are no-brainers that we need to keep  
> in Horde or that don't hurt to have them in Horde.
> What we are really talking about here is the 4th category. And I  
> don't have a single opinion on this one, it really depends on the  
> individual package. Having control over a package, like Michael  
> named it, is a very strong driving point for me. So for packages  
> that are well maintained (by us), or just working and not missing  
> any features, I'm in strong favor of keeping them in Horde.
> Packages that have been contributed but are not a core part of Horde  
> and don't have a maintainer, I could let go more easily (Yaml comes  
> to mind immediately).
>
> When it comes to new packages for future functionality, this is my  
> personal list of criteria to decide whether to fork, whether to  
> re-invent, or whether to use external packages:
> - PEAR installable (showstopper)
> - Code quality and maintenance (soft criterion)
> - Complexity (soft)
>
> A few examples:
> - There is no doubt that the future of DAV functionality in Horde is  
> SabreDAV (unless something even better comes up)
> - I'm pondering to drop Horde_Pdf in favor of TCPDF
> - Yaml might be dropped completely, it has bugs and is unmaintained,  
> and Symfony's package seems to be the de-facto standard these days
> - Migrations support and the possibility to quickly fix issues with  
> such an important area of Horde like DB storage makes want to keep  
> Horde_Db, even though other abstraction layers might be more complete
> - The Log package despite having many counterparts in other  
> frameworks "just works", so I don't see a reason to drop it

I hope I did not create the impression that I wanted to ditch large  
parts of the Horde code base. Definitely not. From your comments and  
the responses it already looks like we are absolutely willing to use  
code from the other frameworks - if there are compelling reasons for  
us to do so. I don't think more than that is needed.

The related topic - allowing others to integrate our components with  
elements from other frameworks - is something where we can still  
improve. But I assume this will happen in time. We have not been a  
component based framework for a long time and I'm certain there will  
be additional progress in that area.

Cheers,

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.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