[Tickets #56] Re: IMP maintenance should apply to a configurable folder set.

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=56
-----------------------------------------------------------------------
 Ticket             | 56
 Updated By         | brook at linuxbox.com
 Summary            | IMP maintenance should apply to a configurable folder set.
 Queue              | IMP
 Version            | HEAD
 Type               | Enhancement
 State              | Stalled
 Priority           | 1. Low
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


brook at linuxbox.com (2007-08-01 09:33) wrote:

> This is *way* too hackish for my taste

While I agree that the one example you give can be considered a hack
(that's where I was hoping the Horde gurus could help me out).  I would
contend that the other portions of the patch adhere to the Horde coding
standards.  If you could cite other examples where it is the case that
other Horde standards have been broken, I'd be open to adjusting the patch
appropriately.

> the framework patch 
> contains numerous references to imp's purge_folder code, which 
> obviously we can't do.

To perhaps clarify, these references are there (as the comments suggest)
because Horde doesn't/didn't allow "special" types to have hooks, or at
least I couldn't find a way to make it work (if you know this not to be the
case, please advise).  I agree with your other comments along those lines,
in that maintenance tasks were never designed to handle these cases in the
first place, and I consider this a shortcoming in the present Horde
framework.  The only reason purge_folders references are made in these two
cases are:

(a) because we want to ensure they can't disable maintenance if the admin
says they can't ( I think this may have already been done by someone else,
so this might not be required anymore).  This was to meet our customer
requirement for disabling the user's ability to skip maintenance and is
non-essential for the functionality required in the feature request.

(b) we wanted to store an array of values under a single preference key
per user, which in Horde, to my knowledge, you can't do while maintaining
hooked functionality, short of defining a whole new 'array' datatype.

I believe it is the case that the remainder of the code (outside those two
cases) adheres to Horde/IMP coding standards, but things may have changed
since we wrote this (nearly a year ago now).  If I remember correctly, the
fact that you have to store each folder's preferences separately with a way
of keying them uniquely was the primary issue.  This was done to adhere to
preference storage and user interface generation standards set forth by the
current maintenance implementation.
 
> maintenance code was never designed to handle this kind of thing in 
> the first place so trying to hack a solution is probably not as good 
> of a solution as reforming the maintenance framework in the first 
> place.

While I agree that Horde should eventually have its entire maintenance
interface rewritten, or at least extended to allow for more flexibility on
specialized datatypes, and thus functionality, I'm guessing this would be a
rather large undertaking.  A more generalized interface on per folder
maintenance tasks, as you suggest, would require either hacking the
framework severely in its current form, or rewriting it entirely.

A more reasonable approach in my mind would be possible if you could offer
advice on how the framework might be minimally modified to more elegantly
allow this specific functionality to exist today.  I'd be glad to work on
it, but I'd need a little guidance.  

The fact that there has been a bounty on this feature for several years
should serve as justification for working towards integrating possible
solutions with the maintenance framework in its current form.  Providing
features such as this in the short-term would probably provide more
incentive to undertake the larger tasks, in my opinion.

I've just gotten some more time delegated at work to assist, which I hope
can be of maximum effectiveness through your team's support, suggestions,
and guidance.

Cheers,

Brook