From sqall at h4des.org Mon Jan 5 13:09:59 2009 From: sqall at h4des.org (Andre Pawlowski) Date: Mon, 05 Jan 2009 14:09:59 +0100 Subject: [dev] How to include "html code" for an app right? Message-ID: <496206A7.4020205@h4des.org> Hi guys, I've got a problem. I'm writing an application for Horde. Everything works fine, but when I look at the html source code it's always like this: ... ... ... HERE IS MY HTML CODE Well, my code for the output is always after the tag. I don't know how I can change this. I've looked at other Horde applications and they have their html source in the tag section. I have no clue how I can do this. Can you tell me how to include my source code to have it in the tag section? Thanks a lot. -- Andre Pawlowski ------------------------------------------------------------------- Genius is one percent inspiration and 99 percent transpiration. -Thomas Alva Edison From mrubinsk at horde.org Mon Jan 5 15:42:17 2009 From: mrubinsk at horde.org (Michael Rubinsky) Date: Mon, 05 Jan 2009 10:42:17 -0500 Subject: [dev] How to include "html code" for an app right? In-Reply-To: <496206A7.4020205@h4des.org> References: <496206A7.4020205@h4des.org> Message-ID: <20090105104217.89592zwz4zh7c0u8@portal.theupstairsroom.com> Quoting Andre Pawlowski : > Hi guys, > > I've got a problem. I'm writing an application for Horde. Everything > works fine, but when I look at the html source code it's always like this: > > > > ... > > ... > > ... > > > HERE IS MY HTML CODE > > Well, my code for the output is always after the tag. I don't > know how I can change this. I've looked at other Horde applications > and they have their html source in the tag section. I have no > clue how I can do this. Can you tell me how to include my source code > to have it in the tag section? This is impossible to answer without knowing the structure of your application's views or templates....you just need to make sure that your outputting your HTML at the appropriate spot. Look at any other horde application to see how they include various templates in relation to the html content the application generates. Thanks, mike -- The Horde Project (www.horde.org) mrubinsk at horde.org "Time just hates me. That's why it made me an adult." - Josh Joplin From sqall at h4des.org Mon Jan 5 16:34:46 2009 From: sqall at h4des.org (Andre Pawlowski) Date: Mon, 05 Jan 2009 17:34:46 +0100 Subject: [dev] How to include "html code" for an app right? In-Reply-To: <20090105104217.89592zwz4zh7c0u8@portal.theupstairsroom.com> References: <496206A7.4020205@h4des.org> <20090105104217.89592zwz4zh7c0u8@portal.theupstairsroom.com> Message-ID: <496236A6.80707@h4des.org> Michael Rubinsky wrote: > > Quoting Andre Pawlowski : > >> >> Well, my code for the output is always after the tag. I >> don't know how I can change this. I've looked at other Horde >> applications and they have their html source in the tag >> section. I have no clue how I can do this. Can you tell me how to >> include my source code to have it in the tag section? > > This is impossible to answer without knowing the structure of your > application's views or templates....you just need to make sure that > your outputting your HTML at the appropriate spot. Look at any > other horde application to see how they include various templates > in relation to the html content the application generates. > > > Thanks, mike > You are right. It's impossible to answer this question. I've took a look at Turba and still don't understand how to include my html code right. Well, Turba includes /lib/base.php and then some other *.inc and the footer.inc. My application uses the skeleton base.php and I include the /lib/base.php as well. But when I include my base.php of the skeleton (its not changed) then I've got a header and a footer and the rest of my html code falls behind the footer. I take a look at the base.php and this only uses some php skripts of Horde which Turba uses as well. Well, perhaps you can help me when I show you the source of the base.php which includes header and footer. pushApp('kastalia', !defined('AUTH_HANDLER'))), 'PEAR_Error')) { if ($pushed->getCode() == 'permission_denied') { Horde::authenticationFailureRedirect(); } Horde::fatal($pushed, __FILE__, __LINE__, false); } $conf = &$GLOBALS['conf']; @define('KASTALIA_TEMPLATES', $registry->get('templates')); // Notification system. $notification = &Notification::singleton(); $notification->attach('status'); // Define the base file path of Kastalia. @define('KASTALIA_BASE', dirname(__FILE__) . '/..'); // Kastalia base library require_once KASTALIA_BASE . '/lib/Kastalia.php'; // Start output compression. Horde::compressOutput(); I hope know it's possible to help me. Thanks. -- Andre Pawlowski ------------------------------------------------------------------- Genius is one percent inspiration and 99 percent transpiration. -Thomas Alva Edison From mrubinsk at horde.org Mon Jan 5 16:50:08 2009 From: mrubinsk at horde.org (Michael Rubinsky) Date: Mon, 05 Jan 2009 11:50:08 -0500 Subject: [dev] How to include "html code" for an app right? In-Reply-To: <496236A6.80707@h4des.org> References: <496206A7.4020205@h4des.org> <20090105104217.89592zwz4zh7c0u8@portal.theupstairsroom.com> <496236A6.80707@h4des.org> Message-ID: <20090105115008.110073hgc0qug6ck@portal.theupstairsroom.com> Andre, It seems that you still need to do a bit of research. It doesn't appear that you understand the structure of a Horde app. Try reading some of the presentations at http://horde.org/papers - in particular there is a good one by Jan http://www.horde.org/papers/fosdem2005/ It might be a bit outdated, but it will probably give you a better understanding of the structure of the app, what code goes where etc.... Quoting Andre Pawlowski : > > > Michael Rubinsky wrote: >> >> Quoting Andre Pawlowski : >> >>> >>> Well, my code for the output is always after the tag. I >>> don't know how I can change this. I've looked at other Horde >>> applications and they have their html source in the tag >>> section. I have no clue how I can do this. Can you tell me how to >>> include my source code to have it in the tag section? >> >> This is impossible to answer without knowing the structure of your >> application's views or templates....you just need to make sure that >> your outputting your HTML at the appropriate spot. Look at any >> other horde application to see how they include various templates >> in relation to the html content the application generates. >> >> >> Thanks, mike >> > You are right. It's impossible to answer this question. I've took a > look at Turba and still don't understand how to include my html code > right. Well, Turba includes /lib/base.php and then some other *.inc > and the footer.inc. > > My application uses the skeleton base.php and I include the > /lib/base.php as well. But when I include my base.php of the skeleton > (its not changed) then I've got a header and a footer and the rest of > my html code falls behind the footer. I take a look at the base.php > and this only uses some php skripts of Horde which Turba uses as well. > > Well, perhaps you can help me when I show you the source of the > base.php which includes header and footer. > > // Check for a prior definition of HORDE_BASE (perhaps by an > auto_prepend_file > // definition for site customization). > if (!defined('HORDE_BASE')) { > @define('HORDE_BASE', dirname(__FILE__) . '/../..'); > } > > // Load the Horde Framework core, and set up inclusion paths. > require_once HORDE_BASE . '/lib/core.php'; > > // Registry. > $registry = &Registry::singleton(); > if (is_a(($pushed = $registry->pushApp('kastalia', > !defined('AUTH_HANDLER'))), 'PEAR_Error')) { > if ($pushed->getCode() == 'permission_denied') { > Horde::authenticationFailureRedirect(); > } > Horde::fatal($pushed, __FILE__, __LINE__, false); > } > $conf = &$GLOBALS['conf']; > @define('KASTALIA_TEMPLATES', $registry->get('templates')); > > // Notification system. > $notification = &Notification::singleton(); > $notification->attach('status'); > > // Define the base file path of Kastalia. > @define('KASTALIA_BASE', dirname(__FILE__) . '/..'); > > // Kastalia base library > require_once KASTALIA_BASE . '/lib/Kastalia.php'; > > // Start output compression. > Horde::compressOutput(); > > I hope know it's possible to help me. Thanks. > > -- > > Andre Pawlowski > > ------------------------------------------------------------------- > > Genius is one percent inspiration and 99 percent transpiration. > -Thomas Alva Edison > > > -- > Horde developers mailing list - Join the hunt: http://horde.org/bounties/ > Frequently Asked Questions: http://horde.org/faq/ > To unsubscribe, mail: dev-unsubscribe at lists.horde.org > Thanks, mike -- The Horde Project (www.horde.org) mrubinsk at horde.org "Time just hates me. That's why it made me an adult." - Josh Joplin From jan at horde.org Wed Jan 7 09:21:22 2009 From: jan at horde.org (Jan Schneider) Date: Wed, 07 Jan 2009 10:21:22 +0100 Subject: [dev] [cvs] commit: chora annotate.php diff.php chora/templates/annotate footer.inc In-Reply-To: <20090107055543.E756A27D27@nazik.horde.org> References: <20090107055543.E756A27D27@nazik.horde.org> Message-ID: <20090107102122.25833ovaw4gzck6c@neo.wg.de> Zitat von Michael M Slusarz : > slusarz 2009-01-07 00:55:43 EST > > Modified files: > . annotate.php diff.php > Removed files: > templates/annotate footer.inc > Log: > Remove log info on annotate page. This can create gigantic HTML > output, does > not work with git revision strings, and doesn't work with git output anyway > (due to git blame possibly referencing commits in previous files before > renaming, which doesn't work well with the way VCS currently deals > with logs). Uh, this was one of the most useful features of the annotate view. We should at least keep it for non-git repos. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From jan at horde.org Wed Jan 7 09:23:53 2009 From: jan at horde.org (Jan Schneider) Date: Wed, 07 Jan 2009 10:23:53 +0100 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107061307.ED53427D27@nazik.horde.org> References: <20090107061307.ED53427D27@nazik.horde.org> Message-ID: <20090107102353.66434r8qdrwgc1wk@neo.wg.de> Zitat von Michael M Slusarz : > slusarz 2009-01-07 01:13:07 EST > > Modified files: > . annotate.php > templates/annotate header.inc line.inc > themes screen.css > Log: > Rework annotate screen - prevision revision number is not all that > important. > What is important is a link to the diff between the changing > revision and the > previous revision (the previous revision can be viewed in its entirety by > following the appropriate link on the diff page). Again, I strongly disagree. I use this all the time to navigate back through history until I find the actual revision where a change was really made, to skip revisions where a change was just cosmetically. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From jan at horde.org Wed Jan 7 09:29:18 2009 From: jan at horde.org (Jan Schneider) Date: Wed, 07 Jan 2009 10:29:18 +0100 Subject: [dev] [cvs] commit: horde/docs CHANGES framework/Util String.php In-Reply-To: <20090107023929.8B2E827D27@nazik.horde.org> References: <20090107023929.8B2E827D27@nazik.horde.org> Message-ID: <20090107102918.45178rvtjt7lqmm8@neo.wg.de> Zitat von Chuck Hagenbuch : > chuck 2009-01-06 21:39:29 EST > > Modified files: (Branch: FRAMEWORK_3) > docs CHANGES > Util String.php > Log: > MFH: > 1.91 +18 -1 framework/Util/String.php > 1.1190 +2 -0 horde/docs/CHANGES > > Revision Changes Path > 1.43.6.33 +18 -1 framework/Util/String.php > 1.515.2.496 +2 -0 horde/docs/CHANGES This is a PHP 5 function. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From mrubinsk at horde.org Wed Jan 7 15:24:41 2009 From: mrubinsk at horde.org (Michael Rubinsky) Date: Wed, 07 Jan 2009 10:24:41 -0500 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107102353.66434r8qdrwgc1wk@neo.wg.de> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> Message-ID: <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> Quoting Jan Schneider : > Zitat von Michael M Slusarz : > >> slusarz 2009-01-07 01:13:07 EST >> >> Modified files: >> . annotate.php >> templates/annotate header.inc line.inc >> themes screen.css >> Log: >> Rework annotate screen - prevision revision number is not all that >> important. >> What is important is a link to the diff between the changing >> revision and the >> previous revision (the previous revision can be viewed in its entirety by >> following the appropriate link on the diff page). > > Again, I strongly disagree. I use this all the time to navigate back > through history until I find the actual revision where a change was > really made, to skip revisions where a change was just cosmetically. I agree with Jan on this (as well as the log info remaining in the annotate view). IMO, an awful lot of the reason for me using annotate (at least with non-git repos) is lost with these changes. Thanks, mike -- The Horde Project (www.horde.org) mrubinsk at horde.org "Time just hates me. That's why it made me an adult." - Josh Joplin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: PGP Digital Signature URL: From slusarz at horde.org Wed Jan 7 17:31:03 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Wed, 07 Jan 2009 10:31:03 -0700 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> Message-ID: <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> Quoting Michael Rubinsky : > Quoting Jan Schneider : > >> Zitat von Michael M Slusarz : >> >>> slusarz 2009-01-07 01:13:07 EST >>> >>> Modified files: >>> . annotate.php >>> templates/annotate header.inc line.inc >>> themes screen.css >>> Log: >>> Rework annotate screen - prevision revision number is not all that >>> important. >>> What is important is a link to the diff between the changing >>> revision and the >>> previous revision (the previous revision can be viewed in its entirety by >>> following the appropriate link on the diff page). >> >> Again, I strongly disagree. I use this all the time to navigate back >> through history until I find the actual revision where a change was >> really made, to skip revisions where a change was just cosmetically. > > > I agree with Jan on this (as well as the log info remaining in the > annotate view). IMO, an awful lot of the reason for me using annotate > (at least with non-git repos) is lost with these changes. Apparently the way I use annotate is completely different than everyone else (although, from past history, that doesn't surprise me :)) My problem with the way that everyone else does things is the following: if you click on the previous revision, and the change you are looking for is at line 5000, are you saying you have to scroll all the way down to line 5000 and then manually eyeball the section to see if it changes? That is entirely unacceptable to me. It makes a lot more sense to view a diff between the two revisions which, depending on the size of the commit, won't require scrolling at all. Then if the change is cosmetic only, you can click on the previous revision on the diff screen to go to that revision, and then you can click on Annotate on that page. Granted it does require an extra click to get to the next annotation, but on the flip side the server is doing all the comparing rather than your eyeballs. Still heartily disagree with the log tooltip. Given the existence of the diff icon now, the log tooltip is complete overkill and (with large files) is a total resource hog. I can actually view imp/lib/Compose.php now without it threatening to crash my browser (we're talking about a dual core CPU with many GB of memory) - which was one of the reasons that made me change this in the first place. Additionally, as previously mentioned, displaying log entries for git files that have been renamed is a non-trivial thing. git rev-list only displays revisions for the file as currently named. If changes were made before the file was renamed, then you have to go produce a log entry of that entire file and so-on until the git repo origin is reached. I guess the solution for the former is to re-add the Previous column. As for the log tooltip, if re-added, this would make most sense as a tooltip to the diff icon. michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Wed Jan 7 17:50:15 2009 From: jan at horde.org (Jan Schneider) Date: Wed, 07 Jan 2009 18:50:15 +0100 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> Message-ID: <20090107185015.10681a3379r9hutc@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Michael Rubinsky : > >> Quoting Jan Schneider : >> >>> Zitat von Michael M Slusarz : >>> >>>> slusarz 2009-01-07 01:13:07 EST >>>> >>>> Modified files: >>>> . annotate.php >>>> templates/annotate header.inc line.inc >>>> themes screen.css >>>> Log: >>>> Rework annotate screen - prevision revision number is not all that >>>> important. >>>> What is important is a link to the diff between the changing >>>> revision and the >>>> previous revision (the previous revision can be viewed in its entirety by >>>> following the appropriate link on the diff page). >>> >>> Again, I strongly disagree. I use this all the time to navigate back >>> through history until I find the actual revision where a change was >>> really made, to skip revisions where a change was just cosmetically. >> >> >> I agree with Jan on this (as well as the log info remaining in the >> annotate view). IMO, an awful lot of the reason for me using annotate >> (at least with non-git repos) is lost with these changes. > > Apparently the way I use annotate is completely different than > everyone else (although, from past history, that doesn't surprise me > :)) My problem with the way that everyone else does things is the > following: if you click on the previous revision, and the change you > are looking for is at line 5000, are you saying you have to scroll > all the way down to line 5000 and then manually eyeball the section > to see if it changes? That is entirely unacceptable to me. It makes That's exactly how I use it, and the good thing is that it already scrolls down for you to that line. It's not always accurate of course, because the line number is just used 1:1, but it's a good approximate. > a lot more sense to view a diff between the two revisions which, > depending on the size of the commit, won't require scrolling at all. > Then if the change is cosmetic only, you can click on the previous > revision on the diff screen to go to that revision, and then you can > click on Annotate on that page. Granted it does require an extra > click to get to the next annotation, but on the flip side the server > is doing all the comparing rather than your eyeballs. > > Still heartily disagree with the log tooltip. Given the existence > of the diff icon now, the log tooltip is complete overkill and (with > large files) is a total resource hog. I can actually view > imp/lib/Compose.php now without it threatening to crash my browser > (we're talking about a dual core CPU with many GB of memory) - which > was one of the reasons that made me change this in the first place. > Additionally, as previously mentioned, displaying log entries for > git files that have been renamed is a non-trivial thing. git > rev-list only displays revisions for the file as currently named. > If changes were made before the file was renamed, then you have to > go produce a log entry of that entire file and so-on until the git > repo origin is reached. I agree that the log tooltip is a huge resource hog and I alway disliked that. But it's really helpful if you use history/annotation like above, because you can often see with a single look whether the linked diff is really what you are looking for. I think it would be great to load the tooltip with an ajax request instead, that would get us the full feature without the performance loss. > I guess the solution for the former is to re-add the Previous > column. As for the log tooltip, if re-added, this would make most > sense as a tooltip to the diff icon. Agreed, a diff icon (if you talk about adding one to the annotate view) is the better place for the log tooltip. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From slusarz at horde.org Wed Jan 7 19:49:23 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Wed, 07 Jan 2009 12:49:23 -0700 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107185015.10681a3379r9hutc@neo.wg.de> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> <20090107185015.10681a3379r9hutc@neo.wg.de> Message-ID: <20090107124923.22kw7ytqlrxcowkg8g8c0s4sgg8ks0sokcw0@bigworm.curecanti.org> Quoting Jan Schneider : > I agree that the log tooltip is a huge resource hog and I alway > disliked that. But it's really helpful if you use history/annotation > like above, because you can often see with a single look whether the > linked diff is really what you are looking for. > I think it would be great to load the tooltip with an ajax request > instead, that would get us the full feature without the performance > loss. That's what I was going to suggest - of course it's the solution that requires the most work :(. I would suggest that instead of a tooltip, we implement some sort of toggle div instead (i.e. using +/- icon) - this would limit any log display to only entries the user explicitly wants to view. >> I guess the solution for the former is to re-add the Previous >> column. As for the log tooltip, if re-added, this would make most >> sense as a tooltip to the diff icon. > > Agreed, a diff icon (if you talk about adding one to the annotate > view) is the better place for the log tooltip. The diff icon already exists. Although, as stated above, I think the better solution is not using a tooltip but rather some other display solution. michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Wed Jan 7 22:14:18 2009 From: jan at horde.org (Jan Schneider) Date: Wed, 07 Jan 2009 23:14:18 +0100 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107124923.22kw7ytqlrxcowkg8g8c0s4sgg8ks0sokcw0@bigworm.curecanti.org> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> <20090107185015.10681a3379r9hutc@neo.wg.de> <20090107124923.22kw7ytqlrxcowkg8g8c0s4sgg8ks0sokcw0@bigworm.curecanti.org> Message-ID: <20090107231418.20661cuizyb51w00@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Jan Schneider : > >> I agree that the log tooltip is a huge resource hog and I alway >> disliked that. But it's really helpful if you use history/annotation >> like above, because you can often see with a single look whether the >> linked diff is really what you are looking for. >> I think it would be great to load the tooltip with an ajax request >> instead, that would get us the full feature without the performance >> loss. > > That's what I was going to suggest - of course it's the solution > that requires the most work :(. I would suggest that instead of a > tooltip, we implement some sort of toggle div instead (i.e. using > +/- icon) - this would limit any log display to only entries the > user explicitly wants to view. Why is this different from a tooltip? It's still only displayed on a user request. This should happen with a short delay to avoid unnecessary request. I envision something like one of those ad/thumbnail tooltips. If we make this generic enough, we could also use it for preview tooltips in IMP, that would speed up the mailbox loading a lot if previews are enabled. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From slusarz at horde.org Thu Jan 8 00:44:06 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Wed, 07 Jan 2009 17:44:06 -0700 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107231418.20661cuizyb51w00@neo.wg.de> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> <20090107185015.10681a3379r9hutc@neo.wg.de> <20090107124923.22kw7ytqlrxcowkg8g8c0s4sgg8ks0sokcw0@bigworm.curecanti.org> <20090107231418.20661cuizyb51w00@neo.wg.de> Message-ID: <20090107174406.ix4h1mqi1s00wc8g40oowkg84kwkskw0s88@bigworm.curecanti.org> Quoting Jan Schneider : > Zitat von Michael M Slusarz : > >> Quoting Jan Schneider : >> >>> I agree that the log tooltip is a huge resource hog and I alway >>> disliked that. But it's really helpful if you use history/annotation >>> like above, because you can often see with a single look whether the >>> linked diff is really what you are looking for. >>> I think it would be great to load the tooltip with an ajax request >>> instead, that would get us the full feature without the performance >>> loss. >> >> That's what I was going to suggest - of course it's the solution >> that requires the most work :(. I would suggest that instead of a >> tooltip, we implement some sort of toggle div instead (i.e. using >> +/- icon) - this would limit any log display to only entries the >> user explicitly wants to view. > > Why is this different from a tooltip? It's still only displayed on a > user request. This should happen with a short delay to avoid > unnecessary request. I envision something like one of those > ad/thumbnail tooltips. If we make this generic enough, we could also > use it for preview tooltips in IMP, that would speed up the mailbox > loading a lot if previews are enabled. I am not a big fan of tooltips in general. And for this sort of function (only wanting log entries to display when the user is 100% sure they want to view a log entry) I prefer a more explicit solution. Additionally, hovering over an icon while requiring a delay doesn't seem completely intuitive to me. Regardless, I have already implemented a solution which adds an extra icon for log entry - when clicked, an AJAX request is triggered and the log entry appears below the entry. IMO, it looks and performs quite well and I am happy with the results. If others want to tinker with this, at least there is a base to expand on. michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Thu Jan 8 02:08:28 2009 From: jan at horde.org (Jan Schneider) Date: Thu, 08 Jan 2009 03:08:28 +0100 Subject: [dev] [cvs] commit: chora annotate.php chora/templates/annotate header.inc line.inc chora/themes screen.css In-Reply-To: <20090107174406.ix4h1mqi1s00wc8g40oowkg84kwkskw0s88@bigworm.curecanti.org> References: <20090107061307.ED53427D27@nazik.horde.org> <20090107102353.66434r8qdrwgc1wk@neo.wg.de> <20090107102441.35475ex6ayg5wogs@portal.theupstairsroom.com> <20090107103103.1jp3kqwsblb4ogs48440kg8w88skk8ckggkwk@bigworm.curecanti.org> <20090107185015.10681a3379r9hutc@neo.wg.de> <20090107124923.22kw7ytqlrxcowkg8g8c0s4sgg8ks0sokcw0@bigworm.curecanti.org> <20090107231418.20661cuizyb51w00@neo.wg.de> <20090107174406.ix4h1mqi1s00wc8g40oowkg84kwkskw0s88@bigworm.curecanti.org> Message-ID: <20090108030828.19595aieni8i47c0@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Jan Schneider : > >> Zitat von Michael M Slusarz : >> >>> Quoting Jan Schneider : >>> >>>> I agree that the log tooltip is a huge resource hog and I alway >>>> disliked that. But it's really helpful if you use history/annotation >>>> like above, because you can often see with a single look whether the >>>> linked diff is really what you are looking for. >>>> I think it would be great to load the tooltip with an ajax request >>>> instead, that would get us the full feature without the performance >>>> loss. >>> >>> That's what I was going to suggest - of course it's the solution >>> that requires the most work :(. I would suggest that instead of a >>> tooltip, we implement some sort of toggle div instead (i.e. using >>> +/- icon) - this would limit any log display to only entries the >>> user explicitly wants to view. >> >> Why is this different from a tooltip? It's still only displayed on a >> user request. This should happen with a short delay to avoid >> unnecessary request. I envision something like one of those >> ad/thumbnail tooltips. If we make this generic enough, we could also >> use it for preview tooltips in IMP, that would speed up the mailbox >> loading a lot if previews are enabled. > > I am not a big fan of tooltips in general. And for this sort of > function (only wanting log entries to display when the user is 100% > sure they want to view a log entry) I prefer a more explicit > solution. Additionally, hovering over an icon while requiring a > delay doesn't seem completely intuitive to me. > > Regardless, I have already implemented a solution which adds an > extra icon for log entry - when clicked, an AJAX request is > triggered and the log entry appears below the entry. IMO, it looks > and performs quite well and I am happy with the results. If others > want to tinker with this, at least there is a base to expand on. That was quick, great! Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From jan at horde.org Thu Jan 8 17:29:57 2009 From: jan at horde.org (Jan Schneider) Date: Thu, 08 Jan 2009 18:29:57 +0100 Subject: [dev] Performance issues with IMP git Message-ID: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> Does anybody else see really bad performance using IMP from git? I'm talking about over 20 seconds for a page request, no matter whether viewing a single message or a virtual folder. Further analysis shows that most of the time (each around 40%) is spent in fgets() and feof() called from Horde_Imap_Client_Socket::_getLine(). From message.php they are called 38/36 times, from my virtual inbox 404/372 times. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From slusarz at horde.org Thu Jan 8 17:39:10 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Thu, 08 Jan 2009 10:39:10 -0700 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> Message-ID: <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> Quoting Jan Schneider : > Does anybody else see really bad performance using IMP from git? I'm > talking about over 20 seconds for a page request, no matter whether > viewing a single message or a virtual folder. > Further analysis shows that most of the time (each around 40%) is > spent in fgets() and feof() called from > Horde_Imap_Client_Socket::_getLine(). From message.php they are called > 38/36 times, from my virtual inbox 404/372 times. Nope - instantaneous for me. (I'm glad to get feedback, though. I kind of figured the code wasn't perfect :) ) fgets/feof should be called that many times - those functions should be called once for every line of input read from the stream. Maybe there's an issue with stream blocking on your system - possibly play around with socket_set_blocking() and see if that fixes things(?) michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Thu Jan 8 18:01:49 2009 From: jan at horde.org (Jan Schneider) Date: Thu, 08 Jan 2009 19:01:49 +0100 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> Message-ID: <20090108190149.35616t0beouuxusk@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Jan Schneider : > >> Does anybody else see really bad performance using IMP from git? I'm >> talking about over 20 seconds for a page request, no matter whether >> viewing a single message or a virtual folder. >> Further analysis shows that most of the time (each around 40%) is >> spent in fgets() and feof() called from >> Horde_Imap_Client_Socket::_getLine(). From message.php they are called >> 38/36 times, from my virtual inbox 404/372 times. > > Nope - instantaneous for me. (I'm glad to get feedback, though. I > kind of figured the code wasn't perfect :) ) > > fgets/feof should be called that many times - those functions should > be called once for every line of input read from the stream. Maybe > there's an issue with stream blocking on your system - possibly play > around with socket_set_blocking() and see if that fixes things(?) Further digging showed that almost 99% of this delay seems to be caused by imap requests from the login methods. Using the test_client.php from framework returns instantaneously though. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From slusarz at horde.org Thu Jan 8 18:08:03 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Thu, 08 Jan 2009 11:08:03 -0700 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108190149.35616t0beouuxusk@neo.wg.de> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> <20090108190149.35616t0beouuxusk@neo.wg.de> Message-ID: <20090108110803.k408400kg4wk@bigworm.curecanti.org> Quoting Jan Schneider : > Zitat von Michael M Slusarz : > >> Quoting Jan Schneider : >> >>> Does anybody else see really bad performance using IMP from git? I'm >>> talking about over 20 seconds for a page request, no matter whether >>> viewing a single message or a virtual folder. >>> Further analysis shows that most of the time (each around 40%) is >>> spent in fgets() and feof() called from >>> Horde_Imap_Client_Socket::_getLine(). From message.php they are called >>> 38/36 times, from my virtual inbox 404/372 times. >> >> Nope - instantaneous for me. (I'm glad to get feedback, though. I >> kind of figured the code wasn't perfect :) ) >> >> fgets/feof should be called that many times - those functions should >> be called once for every line of input read from the stream. Maybe >> there's an issue with stream blocking on your system - possibly play >> around with socket_set_blocking() and see if that fixes things(?) > > Further digging showed that almost 99% of this delay seems to be > caused by imap requests from the login methods. Using the > test_client.php from framework returns instantaneously though. Have you turned on IMAP debug logging (great new feature in IMP 5!)? To dump to a text file, simply add: 'debug' => 'path_to_filename' in imp/config/servers.php. michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Thu Jan 8 18:26:50 2009 From: jan at horde.org (Jan Schneider) Date: Thu, 08 Jan 2009 19:26:50 +0100 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108110803.k408400kg4wk@bigworm.curecanti.org> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> <20090108190149.35616t0beouuxusk@neo.wg.de> <20090108110803.k408400kg4wk@bigworm.curecanti.org> Message-ID: <20090108192650.18433xaz44a0eao0@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Jan Schneider : > >> Zitat von Michael M Slusarz : >> >>> Quoting Jan Schneider : >>> >>>> Does anybody else see really bad performance using IMP from git? I'm >>>> talking about over 20 seconds for a page request, no matter whether >>>> viewing a single message or a virtual folder. >>>> Further analysis shows that most of the time (each around 40%) is >>>> spent in fgets() and feof() called from >>>> Horde_Imap_Client_Socket::_getLine(). From message.php they are called >>>> 38/36 times, from my virtual inbox 404/372 times. >>> >>> Nope - instantaneous for me. (I'm glad to get feedback, though. I >>> kind of figured the code wasn't perfect :) ) >>> >>> fgets/feof should be called that many times - those functions should >>> be called once for every line of input read from the stream. Maybe >>> there's an issue with stream blocking on your system - possibly play >>> around with socket_set_blocking() and see if that fixes things(?) >> >> Further digging showed that almost 99% of this delay seems to be >> caused by imap requests from the login methods. Using the >> test_client.php from framework returns instantaneously though. > > Have you turned on IMAP debug logging (great new feature in IMP 5!)? > To dump to a text file, simply add: > 'debug' => 'path_to_filename' > in imp/config/servers.php. Yes, I already did this and also added timestamps to the log message. Blocking/non-blocking doesn't make a difference, authentication always takes exactly 10 seconds. Does that ring a bell? Here's a typical log excerpt: S (1231438991,2811): * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR] neo Cyrus IMAP4 v2.3.11 server ready C (1231438991,2817): 1 AUTHENTICATE PLAIN S (1231438991,2818): + C (1231439011,2861): [AUTHENTICATE Command] S (1231439011,4143): 1 OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE X-NETSCAPE URLAUTH] Success (no protection) C (1231439011,4542): 2 EXAMINE "INBOX" S (1231439011,4548): * FLAGS (\Answered \Flagged \Draft \Deleted \Seen NonJunk $Label2 $Label1 $Label3 $Label4 $Label5 Junk $Forwarded NotJunk foo AMMMa Consulting $NotJunk JunkRecorded $Junk Training $MDNSent KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $TODO $WATCHED $IGNORED) S (1231439011,4562): * OK [PERMANENTFLAGS ()] S (1231439011,4564): * 77 EXISTS S (1231439011,4566): * 0 RECENT S (1231439011,4568): * OK [UNSEEN 67] S (1231439011,4569): * OK [UIDVALIDITY 968256253] S (1231439011,457): * OK [UIDNEXT 194879] S (1231439011,4571): * OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox S (1231439011,4572): * OK [URLMECH INTERNAL] S (1231439011,4573): 2 OK [READ-ONLY] Completed ... Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From slusarz at horde.org Thu Jan 8 18:40:22 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Thu, 08 Jan 2009 11:40:22 -0700 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108192650.18433xaz44a0eao0@neo.wg.de> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> <20090108190149.35616t0beouuxusk@neo.wg.de> <20090108110803.k408400kg4wk@bigworm.curecanti.org> <20090108192650.18433xaz44a0eao0@neo.wg.de> Message-ID: <20090108114022.k484s8w4wgkw@bigworm.curecanti.org> Quoting Jan Schneider : > Yes, I already did this and also added timestamps to the log message. > Blocking/non-blocking doesn't make a difference, authentication always > takes exactly 10 seconds. Does that ring a bell? Here's a typical log > excerpt: > > S (1231438991,2811): * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID > STARTTLS AUTH=PLAIN SASL-IR] neo Cyrus IMAP4 v2.3.11 server ready > C (1231438991,2817): 1 AUTHENTICATE PLAIN > S (1231438991,2818): + [10 seconds] > C (1231439011,2861): [AUTHENTICATE Command] Considering there is a 10 second timeout on socket reads, that's definitely the issue. For whatever reason, the response parsing code is not recognizing the continuation request for the IMAP server. I could have sworn that I dealt with this issue in the past... michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Thu Jan 8 18:49:04 2009 From: jan at horde.org (Jan Schneider) Date: Thu, 08 Jan 2009 19:49:04 +0100 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108114022.k484s8w4wgkw@bigworm.curecanti.org> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> <20090108190149.35616t0beouuxusk@neo.wg.de> <20090108110803.k408400kg4wk@bigworm.curecanti.org> <20090108192650.18433xaz44a0eao0@neo.wg.de> <20090108114022.k484s8w4wgkw@bigworm.curecanti.org> Message-ID: <20090108194904.17542byb9ybaatog@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Jan Schneider : > >> Yes, I already did this and also added timestamps to the log message. >> Blocking/non-blocking doesn't make a difference, authentication always >> takes exactly 10 seconds. Does that ring a bell? Here's a typical log >> excerpt: >> >> S (1231438991,2811): * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID >> STARTTLS AUTH=PLAIN SASL-IR] neo Cyrus IMAP4 v2.3.11 server ready >> C (1231438991,2817): 1 AUTHENTICATE PLAIN >> S (1231438991,2818): + > > [10 seconds] > >> C (1231439011,2861): [AUTHENTICATE Command] > > Considering there is a 10 second timeout on socket reads, that's > definitely the issue. For whatever reason, the response parsing > code is not recognizing the continuation request for the IMAP > server. I could have sworn that I dealt with this issue in the > past... Yes, you did, because of my reports with test_client.php. It didn't work at all in the past, it works now, just with that weird delay. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From slusarz at horde.org Thu Jan 8 19:04:21 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Thu, 08 Jan 2009 12:04:21 -0700 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108192650.18433xaz44a0eao0@neo.wg.de> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> <20090108190149.35616t0beouuxusk@neo.wg.de> <20090108110803.k408400kg4wk@bigworm.curecanti.org> <20090108192650.18433xaz44a0eao0@neo.wg.de> Message-ID: <20090108120421.o08csc0sgkwk@bigworm.curecanti.org> Quoting Jan Schneider : > S (1231438991,2811): * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID > STARTTLS AUTH=PLAIN SASL-IR] neo Cyrus IMAP4 v2.3.11 server ready > C (1231438991,2817): 1 AUTHENTICATE PLAIN Looking at this a bit deeper, another issue is why SASL-IR authentication is not being used? If SASL-IR is supported, we should be sending a '1 AUTHENTICATE PLAIN *AUTHDATA*' request. A-ha. Looks like the issue has to do with caching of the capability string. Reading the RFC's, it is clear that the server does not have to send a full list of capabilities before the user is authenticated. If this is the case, the server MUST send the full list once authenticated. However, it is a bit unclear whether this full capability list must include ALL capabilities of the server (as every IMAP server I know of except Cyrus does) or only a list of capabilities not associated with authentication (as Cyrus does). Even though I think the way Cyrus does it is incorrect, that is irrelevant for purposes of writing a client to interact. So once we login, and Cyrus automatically sends the capability list as part of the response to the authentication list, we grab this list because we are assuming it to be the full list. When the Imap ob is cached, this is the list that is used the next time it is unserialized. We ignore the capability list given by the server on initial connect (since we already have the list of capabilities). Since the list doesn't include SASL-IR, this is why we default to regular authentication mode. Still doesn't explain why the server is hanging there, but solves the issue why SASL-IR is not being used. This would explain why the test script works fine but IMP doesn't (due to the serialization). Try the fix I just committed to Socket.php. michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From chuck at horde.org Thu Jan 8 20:35:49 2009 From: chuck at horde.org (Chuck Hagenbuch) Date: Thu, 08 Jan 2009 15:35:49 -0500 Subject: [dev] [cvs] commit: chora/lib Chora.php In-Reply-To: <20090108191308.17FC127C4E@nazik.horde.org> References: <20090108191308.17FC127C4E@nazik.horde.org> Message-ID: <20090108153549.17qwm4xcuvtlyscgc@hagenbu.ch> Quoting Michael M Slusarz : > Log: > CVS is the only VC driver that supports branches. For the CVS version, > explicitly do object type checking. Though we still intend to support branches in git, right? -chuck From slusarz at horde.org Thu Jan 8 20:39:41 2009 From: slusarz at horde.org (Michael M Slusarz) Date: Thu, 08 Jan 2009 13:39:41 -0700 Subject: [dev] [cvs] commit: chora/lib Chora.php In-Reply-To: <20090108153549.17qwm4xcuvtlyscgc@hagenbu.ch> References: <20090108191308.17FC127C4E@nazik.horde.org> <20090108153549.17qwm4xcuvtlyscgc@hagenbu.ch> Message-ID: <20090108133941.o88s88g0g040@bigworm.curecanti.org> Quoting Chuck Hagenbuch : > Quoting Michael M Slusarz : > >> Log: >> CVS is the only VC driver that supports branches. For the CVS version, >> explicitly do object type checking. > > Though we still intend to support branches in git, right? At some point, yes. michael -- ___________________________________ Michael Slusarz [slusarz at horde.org] From jan at horde.org Thu Jan 8 22:04:22 2009 From: jan at horde.org (Jan Schneider) Date: Thu, 08 Jan 2009 23:04:22 +0100 Subject: [dev] Performance issues with IMP git In-Reply-To: <20090108120421.o08csc0sgkwk@bigworm.curecanti.org> References: <20090108182957.11571uxpwdvpzu4k@neo.wg.de> <20090108103910.8wwos8wsw48o@bigworm.curecanti.org> <20090108190149.35616t0beouuxusk@neo.wg.de> <20090108110803.k408400kg4wk@bigworm.curecanti.org> <20090108192650.18433xaz44a0eao0@neo.wg.de> <20090108120421.o08csc0sgkwk@bigworm.curecanti.org> Message-ID: <20090108230422.13526ldn3ndgbp8g@neo.wg.de> Zitat von Michael M Slusarz : > Quoting Jan Schneider : > >> S (1231438991,2811): * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID >> STARTTLS AUTH=PLAIN SASL-IR] neo Cyrus IMAP4 v2.3.11 server ready >> C (1231438991,2817): 1 AUTHENTICATE PLAIN > > Looking at this a bit deeper, another issue is why SASL-IR > authentication is not being used? If SASL-IR is supported, we > should be sending a '1 AUTHENTICATE PLAIN *AUTHDATA*' request. > > A-ha. Looks like the issue has to do with caching of the capability > string. Reading the RFC's, it is clear that the server does not > have to send a full list of capabilities before the user is > authenticated. If this is the case, the server MUST send the full > list once authenticated. However, it is a bit unclear whether this > full capability list must include ALL capabilities of the server (as > every IMAP server I know of except Cyrus does) or only a list of > capabilities not associated with authentication (as Cyrus does). > Even though I think the way Cyrus does it is incorrect, that is > irrelevant for purposes of writing a client to interact. > > So once we login, and Cyrus automatically sends the capability list > as part of the response to the authentication list, we grab this > list because we are assuming it to be the full list. When the Imap > ob is cached, this is the list that is used the next time it is > unserialized. We ignore the capability list given by the server on > initial connect (since we already have the list of capabilities). > Since the list doesn't include SASL-IR, this is why we default to > regular authentication mode. Still doesn't explain why the server > is hanging there, but solves the issue why SASL-IR is not being used. > > This would explain why the test script works fine but IMP doesn't > (due to the serialization). Try the fix I just committed to > Socket.php. Yes, that did it. SASL-IR is now used, thus no continuation, thus no delay. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From rsalmon at mbpgroup.com Fri Jan 9 13:37:54 2009 From: rsalmon at mbpgroup.com (Ronan SALMON) Date: Fri, 09 Jan 2009 14:37:54 +0100 Subject: [dev] IMP git: can't run successfully test.php Message-ID: <20090109143754.62053p7w9cyknqsk@webmail.mbpgroup.local> Hi, I'm trying to setup IMP git but I'm getting the following error when running imp/test.php : IMP Version * IMP: H4 (5.0-git) Other Horde Applications * gollem: No Gollem provides access to local VFS filesystems to attach files. * ingo: Yes (Version: H3 (2.0-cvs)) * nag: Yes (Version: H3 (3.0-cvs)) * turba: Yes (Version: H3 (3.0-cvs)) PHP Version * PHP Version: 5.2.5 * PHP Major Version: 5.2 * PHP Minor Version: 5 * PHP Version Classification: release * You are running a supported version of PHP. PHP Module Capabilities * Internationalized Domain Names Support: Yes * IMAP Support: Yes * OpenSSL Support: Yes * Tidy support: Yes Miscellaneous PHP Settings * file_uploads enabled: Yes Required IMP Configuration Files * config/conf.php: Yes * config/mime_drivers.php: Yes * config/prefs.php: Yes * config/servers.php: Yes PEAR * PEAR Search Path (PHP's include_path): .:/usr/share/pear:/usr/share/php * PEAR: Yes * Recent PEAR: Yes * Auth_SASL: Yes PHP Mail Server Support Test Fatal error: Class 'Horde_Imap_Client_Exception' not found in /usr/share/pear/Horde/Imap/Client.php on line 164 git framework is installed : # ls /usr/share/pear/Horde/Imap/Client Base.php Cache.php Cclient Cclient.php Exception.php Search Socket.php Sort.php Thread.php Utf7imap.php From jan at horde.org Fri Jan 9 15:02:56 2009 From: jan at horde.org (Jan Schneider) Date: Fri, 09 Jan 2009 16:02:56 +0100 Subject: [dev] IMP git: can't run successfully test.php In-Reply-To: <20090109143754.62053p7w9cyknqsk@webmail.mbpgroup.local> References: <20090109143754.62053p7w9cyknqsk@webmail.mbpgroup.local> Message-ID: <20090109160256.1510618fn9oanc84@neo.wg.de> Zitat von Ronan SALMON : > Hi, > > I'm trying to setup IMP git but I'm getting the following error when > running imp/test.php : > IMP Version > > * IMP: H4 (5.0-git) > PHP Mail Server Support Test > > Fatal error: Class 'Horde_Imap_Client_Exception' not found in > /usr/share/pear/Horde/Imap/Client.php on line 164 > > > > git framework is installed : > # ls /usr/share/pear/Horde/Imap/Client > Base.php Cache.php Cclient Cclient.php Exception.php Search > Socket.php Sort.php Thread.php Utf7imap.php Looks like we don't use the autoloader in test.php. The question is whether we want to rely on the autoloader to work correctly here, but probably we want to. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ From chuck at horde.org Sat Jan 10 17:29:21 2009 From: chuck at horde.org (Chuck Hagenbuch) Date: Sat, 10 Jan 2009 12:29:21 -0500 Subject: [dev] Whupsey archived Message-ID: <20090110122921.17qwm4xcuxzjo0cg8@hagenbu.ch> I've moved whupsey out of the incubator and just archived the code. I think we've moved well beyond needing a C interface to Whups; if we want a command-line client we can write one in PHP, or perl, or python, or ruby, or ... -chuck