6.0.0-git
2020-08-13

[#6559] Application should fail gracefully if prerequisites not installed
Summary Application should fail gracefully if prerequisites not installed
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State Not A Bug
Priority 1. Low
Owners
Requester php (at) ideacode (dot) com
Created 2008-04-02 (4516 days ago)
Due
Updated 2008-04-09 (4509 days ago)
Assigned
Resolved 2008-04-09 (4509 days ago)
Milestone
Patch No

History
2008-04-09 20:27:41 Chuck Hagenbuch Comment #14 Reply to this comment
On the roadmap.... yes. We're working on it.
2008-04-09 19:56:52 php (at) ideacode (dot) com Comment #13 Reply to this comment
First of all, this is a pretty nice patch. Thank you for submitting it.
No problem.
Given these two things - this is only true for two applications, and
we'll be moving to an already-existing, more complete system in the
future - I don't think it makes sense to introduce a separate
dependency mechanism into Horde.
I agree: introducing solutions to soon-to-be-extinct problems is not 
strategically sound.  However, I would suggest -- and this may already 
exist, I've just not gotten to that point in the manual -- that these 
future plans be documented on an up-to-date roadmap so that 
contributors understand your philosophy and direction. :)
2008-04-09 19:41:58 Chuck Hagenbuch Comment #12
State ⇒ Not A Bug
Reply to this comment
First of all, this is a pretty nice patch. Thank you for submitting it.



However, I'm going to stand by my (and Jan and Michael's) stance that 
this isn't a bug. There is a philosophical difference in that I don't 
think it's problematic that a user can cause a misconfigured or 
improperly installed application to emit a fatal error. It's perhaps 
not ideal, but it's not horrible. Fatal errors from a properly 
installed and configured app are different of course.



My main reason for rejecting this, though, is that:



a. DIMP and MIMP are the only Horde applications that require any 
other Horde application in this way, and the next version will fold 
them both in to IMP, eliminating this situation.



b. PEAR already provides an extensive dependency mechanism, and it is 
our goal to make Horde applications PEAR-installable in the future.



Given these two things - this is only true for two applications, and 
we'll be moving to an already-existing, more complete system in the 
future - I don't think it makes sense to introduce a separate 
dependency mechanism into Horde.
2008-04-06 17:57:22 Michael Slusarz Summary ⇒ Application should fail gracefully if prerequisites not installed
 
2008-04-06 17:56:02 Michael Slusarz Version ⇒ HEAD
Queue ⇒ Horde Framework Packages
 
2008-04-05 19:11:56 Chuck Hagenbuch State ⇒ Unconfirmed
 
2008-04-02 19:21:18 php (at) ideacode (dot) com Comment #11 Reply to this comment
And are you seriously suggesting that we remove requirements from the
documentation?
No, not at all.  I'm saying the software should know the requirements, 
and the documentation should state the requirements, and both should 
agree.  My patch allows developers to codify the application 
requirements in the conf.xml file.  From that, Horde setup emits 
warnings if some requirement isn't met, cluing the administrator that 
there is a problem.  Additionally, the documented requirements can be 
parsed directly out of the conf.xml file so that both software and 
documentation agree on the requirements, all the time.
2008-04-02 19:18:20 php (at) ideacode (dot) com Comment #10 Reply to this comment
There's still some fundamental confusion here. Horde does not require
IMP (or DIMP). DIMP _does_ require IMP. You keep making statements
that contradict one or both of these. Why?
(I'm quite sick, so pardon me if some of my statements are loopy.)



You are right. I misunderstood Michael -- when I looked at his link, I 
thought "that's Horde's (base) install file which is saying IMP is 
required".  When in fact it's DIMP's INSTALL file that says IMP is 
required.  So scratch all my rants related to Horde and IMP.
2008-04-02 18:44:56 Chuck Hagenbuch Comment #9 Reply to this comment
And are you seriously suggesting that we remove requirements from the 
documentation?
2008-04-02 18:44:37 Chuck Hagenbuch Comment #8 Reply to this comment
There's still some fundamental confusion here. Horde does not require 
IMP (or DIMP). DIMP _does_ require IMP. You keep making statements 
that contradict one or both of these. Why?
2008-04-02 18:42:20 php (at) ideacode (dot) com Comment #7 Reply to this comment
And further, now you can take the IMP requirement out of the 
documentation and ram it into the software, with the following added 
to horde/conf.xml:

  <requires>

    <require app='imp' />

  </requires>



So now user's errors are handled more gracefully and with less traffic 
on the bugs list.
2008-04-02 18:26:54 php (at) ideacode (dot) com Comment #6
New Attachment: issue6559.diff Download
Reply to this comment
I appreciate the thought that the application should degrade
gracefully even if random files are deleted from it - which is along
the same lines as saying it should function without its requirements
installed - but there's, to be buzzwordy about it, low ROI there for
an open source project.
A requirement in the documentation is only as good as its enforcement 
in the software.  If IMP is a required module, then I should not be 
able to run a Horde framework with only nag, mnemo, whups, and wicked. 
  But I can, which demonstrates a discrepancy between what the 
documentation states are requirements and what the software states are 
requirements.  In the presence of such a discrepancy, the software's 
view wins.
And I'm sorry, but how is IMP not a requirement for DIMP?
Foremost because the software doesn't enforce the requirement.  I 
recognize the documentation states that IMP is a requirement, and 
that's great, but the reality is that Horde (the collection) is a 
complex organism, comprised of many different modules all with 
differing requirements and implementation strategies, constrained by a 
loose hegemony armed with guidelines designed to move everyone toward 
a common goal.  Recognizing that complexity, the purpose of this 
request -- as low a priority as it may be -- is to provide a product 
that remains strong in the face of users' errors.



And since I'm the type of guy to put my mouth where my bug reports 
are, here's a patch.  This patch adds "requirement" support to 
configuration XML documents.  The completely optional <requires> 
container lists the mandatory applications that the given 
configuration needs.  DIMP, for example, might read:

  <requires>

    <require app="imp" />

    <require extension="imap" />

  </requires>



All requirements must be satisfied, or a warning is emitted on the 
configuration page.  In this case, both the imp application and the 
PHP imap extension must be installed and loaded.  The parser also 
supports a version attribute for the requirement element, but I do not 
immediately know how to get the version information consistently from 
the registry or from an extension, so that's left as an exercise for 
the reader.
2008-04-02 16:35:50 Chuck Hagenbuch Comment #5 Reply to this comment
I appreciate the thought that the application should degrade 
gracefully even if random files are deleted from it - which is along 
the same lines as saying it should function without its requirements 
installed - but there's, to be buzzwordy about it, low ROI there for 
an open source project.



And I'm sorry, but how is IMP not a requirement for DIMP?
2008-04-02 16:32:11 Jan Schneider Comment #4 Reply to this comment
It *is* not a bug.
2008-04-02 16:11:01 php (at) ideacode (dot) com Comment #3 Reply to this comment
http://cvs.horde.org/co.php?r=1.12&f=dimp%2Fdocs%2FINSTALL

IMP is the first prerequisite listed in the INSTALL file.  We are not
going to waste CPU cycles on every page load checking for mandatory
prerequisites that are clearly indicated in the documentation.
First, if a user can cause the application to emit a Fatal PHP Error, 
that is most definitely a bug.



Second, IMP is not a prerequisite -- the documentation is wrong: you 
can load the framework and run nag, mnemo, whups, and wicked without 
any complaints from said applications.



Third, my suggestion was to prevent DIMP from be configured (under 
Administration) if IMP is not first configured.  That would have a 
cost only at administrative setup time, which is a most rare use case.



Finally, I strongly disagree that this ticket should be closed as "Not a Bug".
2008-04-02 15:54:05 Michael Slusarz Comment #2
State ⇒ Not A Bug
Reply to this comment
http://cvs.horde.org/co.php?r=1.12&f=dimp%2Fdocs%2FINSTALL



IMP is the first prerequisite listed in the INSTALL file.  We are not 
going to waste CPU cycles on every page load checking for mandatory 
prerequisites that are clearly indicated in the documentation.
2008-04-02 15:45:39 php (at) ideacode (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ DIMP should fail gracefully if IMP not installed
Queue ⇒ DIMP
Milestone ⇒
Patch ⇒ No
Reply to this comment
Running from the 1-Apr-2008 CVS snapshots, DIMP installed into an 
operational Horde framework without IMP allows you to configure DIMP, 
but when clicking Options for DIMP generates a PHP fatal error:

Fatal error: require_once() [function.require]: Failed opening 
required 
'/home/bishop/www/staging/horde/config/../imp/lib/Notification/Listener/status.php' (include_path='.:/usr/local/lib/php/') in /home/bishop/www/staging/horde/dimp/lib/Notification/Listener/status.php on line 
3



DIMP should gracefully degrade in this situation, perhaps by providing 
a nice message stating that IMP is not installed.  Better, IMO, would 
be to prevent DIMP configuration absent a configured IMP install.

Saved Queries