[dev] Horde as a framework

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> 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

This all sounds right to me.

I also don't want to lose the other point I was trying to make, which  
is that documenting, blogging, and building a dev ecosystem around the  
packages we continue writing ourselves will help a ton, and there are  
some good blueprints out there now for how to do that.

Seems like Gunnar has even been pushing this forward before I started  
the thread. So awesome on that. :)

-chuck