[dev] Horde as a framework

[Jan Schneider]

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

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/