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

* Your Email Address
* Spam protection	Enter the letters below: .___.__ . . __ .__ [__ [__)\|__\|/ `\| \ [___\| \| \|\__.\|__/
Comment	>> 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
Attachment
Watch this ticket

Saved Queries