[dev] Constructive Criticism/Venting

Wed Mar 12 14:13:59 UTC 2014

Quoting Michael M Slusarz <slusarz at horde.org>:

> Just a random e-mail to share some thoughts.  Some come from  
> experience refactoring several things over the last month or so.   
> Some come from reading e-mails and bug reports.
>
> * Horde_Core a a package is completely unnecessary.  It really makes  
> no sense separate from the horde application.  For H6 I see no  
> reason not to combine the two (they are identical to upgrade.)

I disagree. It allows a fix/update to Core functionality to be pushed  
without requiring a full fledged Horde release. I think that, alone,  
is worth it. If we get rid of Horde_Core a majority of bug fixes to  
general horde functionality would have to wait until an app release,  
which due to current time constraints, usually takes longer than  
pushing a library update.

> * Type hinting is not tremendously useful, and in fact can be a  
> hinderance.  Example: we were noticing that Horde_Imap_Client, when  
> unserialized in IMP (which will happen on every access except  
> logins), would recreate a cache object that would be entirely  
> separate from the global Horde object.  To get around this, I  
> decided to use the old wrapper trick - create a wrapper library that  
> does nothing more than have access to the global instance when  
> unserialized.  This can/should be accomplished without doing  
> something like having to extend the entire Horde_Imap_Client_Cache  
> class.  However, due to type hinting, this wasn't possible.  This  
> calls into doubt the usefulness of type hinting.  Especially since...

I agree it can be a pain and require some workarounds, but it allows  
us to enforce a method's contract without having to add a poor-man's  
type checking using if/typeof clauses. I guess it's a matter of which  
trade off is more important to us.

> * Dependency injection is useless IMHO.  We really aren't using it,  
> so most/much of Horde_Injector functionality is unnecessary  
> overhead.  E.g. as our AJAX processes become smaller, the  
> Horde_Injector overhead because a greater part of the process  
> runtime.  IIRC, it now takes up to 10%, for things we don't use -  
> like Reflection analysis on every access (maybe this can be  
> optimized/cached).  For our (Horde applications) purposes,  
> dependency injection isn't tremendously useful since we may have  
> multiple configurations for the same object - i.e. we have different  
> DB setups for different apps, so each DB object needs to be manually  
> injected.  Not to mention it is almost impossible to try to  
> trace/debug the code when using dependency injection.  I've  
> personally spent hours making small changes in Horde components  
> code, simply because it can be impossible to try to trace where the  
> object is coming from.  Horde_Injector is nice as a way to provide a  
> global singleton/configuration store, but that's about it.

I mostly agree, we have so many backends/configuration options that  
using a pure DI solution (as opposed to what we do, and use it mostly  
as a container for singletons) doesn't really work for us. There are a  
few places, however, in the code where we *do* use the injector's  
dependency resolver, so we have to be careful about removing any of  
that functionality. That being said, just because we are not currently  
using it doesn't mean we should abandon it. We want other developers  
to use our libraries, so we shouldn't be making this decision for  
them. I agree we could/should probably refactor things so that stuff  
like the Reflection analysis doesn't run on every page load.

> * We really need to split the git repo (I know, I know, I won't shut  
> up about this).  Whether we like it or not, composer is the package  
> manager of choice going forward (heck: Pirum is deprecated in favor  
> of compose).  And I spent an afternoon trying to get composer to  
> work with our current structure, and it simply doesn't work -- it  
> requires both individual repos and specific tag naming.

I've come to agree that this needs to be done, as I've said before.  
However, we need to delay this until at least H5.2 is released. We  
just don't have the manpower to perform the split, rewrite our  
development tool chain, as well as work on the release/bug fixes  
etc... I do, however, still adamantly stick to my view that we need to  
have the tool chain developed and mostly working before we make the  
official switch.

Composer is another story. I have big concerns about moving to a fully  
Composer managed system. If we do invest more heavily in Composer, I  
think we need to still maintain the pear packages, at least for one  
major release, to ease the pain of downstream packagers - among other  
reasons.

> * Maybe I'm being especially sensitive, but it seems I have seen a  
> LOT of unconstructive criticism lately on the lists.  Of the "Horde  
> sucks!" or "you suck!" or "I upgraded to a new version, and to my  
> surprise it is totally different!  f*** you for changing the code!",  
> or "this software sucks because it is missing 1 feature I want even  
> though it does 99% of what I need. Oh yeah, did I mention that I  
> paid nothing for this software, but that factor is irrelevant. And  
> oh yeah, I realize this is open source and I can fix/change the  
> software to my specifications, or even support the developers to  
> help me out, but no! I demand the software work the way *I* want it  
> to!"  Maybe it's my mid-lifeness catching up to me, but I remember a  
> sunnier time when open source software was a privilege, not a right.  
>  I'm wondering if we've now reached a new normal where people tend  
> to forget this fact.  I'll be the first to thank most of the Horde  
> users that provide useful dialogue/criticisms/input that is integral  
> to any open source project.  But haters are going to hate, and my  
> unscientific subjective census feels the negativity is on the  
> uptick.  And I haven't yet figured out how to program my spam  
> software to filter out emails based on content.

I've been feeling the same. I thought maybe I was just being grumpy  
from having less and less time to code "for free" but I think some of  
it is just human nature - we (and of course, other OSS projects)  
provide fairly quick support/responses/bug fixes in general that  
people have come to expect it. It's not right, but it's the nature of  
the beast. I think the uptick might also be due in part to a bunch of  
providers and downstream packages recently upgrading their installs  
from H4 (or maybe even H3). Doesn't make it right, but really not sure  
what the solution is - especially since it's apparently very easy to  
confuse The Project with The Provider.

OTOH, _some_ of the complaints are valid - a lack of documentation  
being the biggest. Unless end users follow the mailing lists  
constantly, it is very easy to miss the implementation of a new  
feature, or a fix of an existing one. Of course, this all comes back  
to the lack of time we as OSS developers have...
-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20140312/d827f46a/attachment.bin>