[dev] Branches (again), Horde 4.1/5, recent IMAP changes

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> this up again, but I will again raise my frustrations with working  
>> on IMP, especially as it relates to critical code changes.  *NO*  
>> other application relies so heavily on Horde-level code - e.g.  
>> MIME, IMAP, Text_Filtering code - and that makes it extremely  
>> difficult to fix certain items.  It takes me many times longer to  
>> fix an issue, simply because I have to go through the mental  
>> gymnastics of having to figure out how not to break existing APIs.   
>> IMP should not be less stable, or less able to be bugfixed, simply  
>> because it has more of a reliance on global Horde libraries but  
>> unfortunately, that is the case.
>
> What would you suggest the solution to this be? A BC break is a BC  
> break. While your frustration is well deserved and understood,  
> wouldn't this be trading ease of fixing bugs (making things easier  
> for you/us) for less API stability (something that would negatively  
> impact consumers of our code)?

The short answer is "nothing can be done about this".  This is just  
inevitable given our architecture.

The long answer is "Michael S tends to be yelled at the most, because  
he works exclusively on IMP, fixes the largest bugs in IMP, and these  
bugs can't be fixed internally to IMP because (broadly speaking) IMP's  
core is the most dependent on core Horde features.  So he gets  
frustrated and is allowed to b**** about it."

IMP can really be thought of as a frontend to IMAP.  The IMAP code is  
entirely contained within a framework package (and the IMAP code  
(in)directly implicates MIME, MIME Viewer, and Text filtering code, to  
name a few, which are also all part of framework packages.)  Compare  
this with Kronolith (frontend to calendar data defined/stored within  
Kronolith itself), Turba (frontend to contacts data defined/stored  
within Turba itself), Nag (frontend to notes data defined/stored  
within Nag itself), or Ingo (frontend to filters data defined/stored  
within Ingo itself).

End rant.

Gollem is probably the only equivalent application out there that  
relies exclusively on a framework package for its core functionality  
(VFS).

michael

___________________________________
Michael Slusarz [slusarz at horde.org]