[horde] reagent: the code

[Jeff Warnica]

On Sat, 2004-01-05 at 13:01 +0200, Mij wrote:
> Il giorno 26/apr/04, alle 17:38, Chuck Hagenbuch ha scritto:
> 
> > Quoting Mij <mij at bitchx.it>:
> >
> >> horde3 is still quite buggy.
> >
> > Do you have anything to back up this FUD?
> 
> FUD? And fear for what?
> 
> well, more than "buggy" the feeling I had using horde3
> is that its skeleton is completely ready, but that a set of
> those details "required" to appear stable misses.

Not stable and buggy are not the same thing. Either way, Horde 3, and
associated modules are, while the 3-ALPHA release notes makes
disclaimers, unlikely to have API changes. Many sites uses Horde 3 in
production, or at least many individuals use it on live data.


> the INSTALL file is not complete, and some requirement
> is not specified, for example. Two examples are the
> fact that System_command (from PEAR) is needed to
> proceed installing the  "php -q install-packages.php" but
> not requested as "prerequisite".

Within all of Horde3, the framework, and a bunch of modules, the only
thing that needs System_Command is SyncML, which is optional. If
something that Horde explicitly needs requires System_command, then its
your job to chase dependencies. PHP needs (g)libc, but that isn't listed
anywhere.

> Nothing is said about php's configuration, implying the
> requirement the user having the "default" php.ini file,
> while I had to modify something by myself to get half
> of horde working.

I suppose that depends on whose default you use. It "just worked" on my
RH9, RHEL2.95beta, FC-1 box.

> Still, it's nice the whole section about PEAR and PECL,
> while the section where it talks about where to put it
> in the webserver is too quick. Who's not used with horde
> could spend time to know that you can't put it under a
> "http://horde.foobar.com/", pointing it directly to the .../horde/
> folder.

Line 19 of horde/config/registry.php describes, and line 35 defines
defines the "webroot". 

> I got problems with logging to file, then. Can be my fault,
> but I just did its setup from the web panel, prepared any
> file with the right perms, and it doesn't log anything. Don't
> say they don't work, just this is another thing requiring
> a bit of hand work.

Horde logging uses Pear error classes and Pear Log classes. Both are
maintained by non-Horde people.

> Then, you don't feel horde is completely ready for production
> is it's completely unknown "outside": no one major linux
> distribution, nor even the large and very up-to-date freebsd's
> ports tree made it available.

Do any of them make available horde2? Moot point: your using Horde, how
would someone else not using horde influence what version you should
use?

> And finally, the fact that neither the horde project itself provides
> a "stable", "official" horde3 package, as for from the site:
> "horde-3.0-ALPHA.tar.gz"

The very fact that you can download something called
"horde-3.0-ALPHA.tar.gz" from the Horde FTP site makes it official. No,
it is not "stable" as in production quality. While everyone and their
dog defines alpha/beta/production differently (and I don't know how (if
at all) Horde defines them), AND the ALPHA announcement specifically
says that API changes may happen, the plan language of "ALPHA" implies
that Horde3 is in "squash bugs to make ready for release" mode, rather
then "randomly do whatever". Speaking for myself here, as an outside
observer: There was a period of "insanity" a while back when there was
major code rearrangement, stripping things out into the framework
modules; I would not have wanted to be developing something for, but
independent of, horde3 at that point. Today, not so much.


> Please don't get offended by this. As far as I saw so far, horde3
> is amazing in respect of horde2. Besides the more freshy look
> it features, the thing of using conf.xml files to generate config
> panels is just perfect. And it is clear to see the well work you all
> done with it, with a whole "framework".
> 
> What i'm saying is still that its current appearence is not appetible
> for "insitutions" to choose it over horde2.

The question is not if horde2 or horde3 would be used in "insitutions".
Horde3 will eventually be stable (even by your definition) enough for it
to be wildly used.

One important question is: Do you think that you can make your module
"stable" before horde3 becomes "stable"... Do you think you can make
your module appear appealable to institutions before horde can make
horde3 appealable?

Ultimately, the most important question is: How much time do you think
you will waste, as a developer, chasing (potentially, but unlikely)
changing APIs, and will that be less time then you will spend, as a
developer, implementing some of horde3's features into your module now,
and porting your app to horde3 at some time in the future?


> > Especially as opposed to Horde 2.x?
> 
> never find any! horde2 is really nice. Even if h3 is more powerful,
> horde2 does very well its job. And while I just used chora and turba
> with it, I never had problems.