the only thing I would add is DBI and DBD:::CSV, you get a basic prototyping
db and you can add other drivers as you need them. And the package needs to
specify the version of gcc it was built with, so you can add dso's and/or
perl XS modules. I am more a sys admin then a programmer but I would be
willing to build a Solaris package for this. IFF I find the time I would
also look into doing it for FreeBSD and possibility OpenBSD, they both use
the same packaging standard. I will not have time to start this for about 2
weeks though. Please keep in mind that I have no experience with mod_perl
so I would need some noble soul to test the krap out of it.
marc spitzer
----- Original Message -----
From: kevin montuori <[EMAIL PROTECTED]>
To: Aaron E. Ross <[EMAIL PROTECTED]>
Cc: Dave Rolsky <[EMAIL PROTECTED]>; brian moseley <[EMAIL PROTECTED]>; mod_perl
list <[EMAIL PROTECTED]>
Sent: Wednesday, 6. December 2000 17:17
Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection)
> >>> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
