>>> Aaron E Ross writes:
aer> the possibility of being able to untar one package to get
aer> mod_perl w/ persistent db connections, [&c.] is very glamorous!
agreed. but fundamentally impossible. what database are you
going to provide persistent connections to? mysql? not on my
solaris box you're not, unless you're going to include mysql in
your distribution. besides, i want sybase. ok, so skip the
database and use DBM files, gdbm's everywhere, right? again,
not (standard, anyway) on solaris. so, package up gdbm too.
you can see where that's going.
i think providing a mod_perl framework in which applications
can be written is a noble idea. i think recommending a
particular solution is great -- lots of people who hack
mod_perl day in and day out can't keep up with all the new
modules/products, a summary of what's available would be useful
to new programmers and veterans alike.
i also think that this is a case of walking before running:
putting together a summary document of mod_perl development
environments (mason, axkit, ao, &c.) has (to the best of my
knowledge) eluded us so far, the notion that we could bundle
some together and get them to work is pie in the sky thinking.
whoever said that packaging all this stuff together (i think it
was MS or BM) is extremely difficult is absolutely correct.
in my current shop, we have enough trouble creating packages
that work on both solaris 6 and 8 without any modification, and
we're pretty good at this sort of thing.
bundling *just* mod_perl and apache in one package that can be
build and installed by pushing a button seems like an excellent
short term goal. for some people just starting out, you'd be a
folk hero if you provided just this.
(i'm not down on the idea really, but if packaging is going to
be considered as a form of advocacy, it'd be nice if we
attacked it in easy to digest chunks. starting with the two
packages, and perhaps a couple sample applications and moving
on from there.)
aer> except for transaction management, which is apparently of
aer> questionable value,
i don't think anyone is claiming that transaction management is
of questionable value -- when you need it, you need it; there's
no substitute. (unless you consider reconciling databases by
hand a substitute.)
cheers,
k.
--
kevin montuori
support independent booksellers -- http://www.booksense.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
