[dev] Horde as a framework

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> 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).

I had brought this up in the past: I remember specifically singling  
out the Compress package, as something that could probably be booted  
because the functionality is available elsewhere, and it is not a  
core, killer feature offered by Horde.  Maybe it didn't gain traction  
then because there was no easy way, i.e. PEAR, for an end user to  
incorporate an alternative.  That barrier has been removed now.

> 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)

Agreed.  If we are going to do this, the alternative has to be  
something we can easily drop-in replace.

> - The Log package despite having many counterparts in other  
> frameworks "just works", so I don't see a reason to drop it

This is going to be the tough question.  I agree that it doesn't make  
sense to switch Log packages given that our current log package is  
stable, and I don't foresee large maintenance costs.

And for the aforementioned Compress package, it would now be difficult  
to let that go, despite the maintenance costs, since the Horde version  
is the only version I am aware of that can output stream data.

Although I worry we are just going to re-fork in the long run anyway.   
Granted it is a PEAR package, rather than a framework-y package, but  
my experience with the Mail maintainers was less than ideal, and  
necessitated the need for a local Horde fork (the current Mail  
maintainers have no concept of the difference in resource usage  
between huge strings and temp stream resources, and my  
concerns/patches were dismissed because of this lack of knowledge).

michael

___________________________________
Michael Slusarz [slusarz at horde.org]