Re: Smart installing (Re: mod_perl advocacy project resurrection)
At 02:01 PM 12/6/00 -0800, brian moseley wrote: >On Wed, 6 Dec 2000, Aaron E. Ross wrote: > > > while the install and auto configure part is not very glamorous, the > > possibility of being able to untar one package to get mod_perl w/ > persistent > > db connections, transaction management, data relational > modeling/objects and > > a nice templating/servlet engine is very glamorous! you could be a > folk hero! > > > > honestly it seems like a pretty worthwhile project to me. basically, > what is > > missing is (cough! cough!) simply a lot of hard work. > > > > except for transaction management, which is apparently of questionable > value, > > all the pieces exist, right? > > > >database abstraction and connection pooling => DBI > >session management=> Apache::Session > >load balancing=> mod_backhand?? > >data relational mapping => Tangram or Alzabo > >templates or whatever you want to call them => > HTML::Embperl/Mason/TemplateToolkit > >ide => pick an editor with a few hooks to call make, install and restart > > > > granted this may not get us everything, but if we could package up the > stuff > > we all use over and over again, wouldn't that get us pretty far? > > > > Aaron > > > > I'm willing to contribute time to this project if given some input on how > > to proceed. > >perhaps take a look at AO - it's a good start at a servlet >engine that packages at least a few of the items you've >highlighted. i'd love to participate in a project that uses >AO, backhand, an o/r mapping tool, and other components to >provide an out of the box 2-tier system. i'd also love to >see an "enterprise" or 3-tier version of same. let's >organize! > >i suppose i should get the AO sourceforge site up and >running eh? To be fair with regards to application toolkits, there's also SmartWorker.org and our eXtropia stuff. :) We already have 3-tier solutions working on our apps using SOAP as the primary marshalling protocol acting as a proxy to Java versions of our objects. This allows us to do intelligent database and rowset result caching on a multithreaded Java server while the front-end Perl apps just marshall calls in to that server using SOAP. I do wish there were more app toolkits out there as it would create more choice and provide some good experiments about what's a good mechanism for developing apps. eg I found looking at SmartWorker very interesting to see what I liked and did not like and Microsoft ASP for what I liked and didn't like. Of course, I disliked most of Microsoft ASP, but I did like ADO, so we stole the concept and implemented it in Perl and Java (JDO is still not out yet officially from JavaSoft). Of course, app toolkits are tough to write, and then you have to write or find people to write real apps on top of them to validate the design work. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't mean to naysay it, but this is going to start getting quite binary specific. I guess you could maintain an RPM for Linux, but beyond that it seems quite difficult. And even if you maintain it as an RPM for Linux, do you make your own Perl distro with it or use RedHat's crappy distro? Or? On Linux I think installing Apache with Mod_Perl is almost trivial. What might be needed is some shell scripts that automate the process to accompany the readme's. It's the other platforms that are a bear for me personally. But if you made a binary for every platform. Wah! So hard. I think you are better off not touching the binary stuff and sticking to writing a traditional app framework that is not dependent on mod_perl, is not dependent on any database, but can make use of such things. Then, people can upgrade as they see fit. Later, Gunther At 03:54 PM 12/6/00 -0500, Aaron E. Ross wrote: >at a time earlier than now, Dave Rolsky wrote: > > On Wed, 6 Dec 2000, brian moseley wrote: > > > > But I'd also like to point out, as Matt Sergeant said, this stuff is > > _really_ hard, and not very glamorous. I would've done much less of it > > while the install and auto configure part is not very glamorous, the > possibility of being able to untar one package to get mod_perl w/ > persistent > db connections, transaction management, data relational modeling/objects > and > a nice templating/servlet engine is very glamorous! you could be a folk > hero! > > honestly it seems like a pretty worthwhile project to me. basically, what is > missing is (cough! cough!) simply a lot of hard work. > > except for transaction management, which is apparently of questionable > value, > all the pieces exist, right? > >database abstraction and connection pooling => DBI >session management => Apache::Session >load balancing => mod_backhand?? >data relational mapping => Tangram or Alzabo >templates or whatever you want to call them => > HTML::Embperl/Mason/TemplateToolkit >ide => pick an editor with a few hooks to call make, install and restart > > granted this may not get us everything, but if we could package up the stuff > we all use over and over again, wouldn't that get us pretty far? > > Aaron > > I'm willing to contribute time to this project if given some input on how > to proceed. > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Thanks for pointing that out, or I could just use compress. As far as the $$$ goes you need to spend money to start a business lets see if there is a market first. Another thing we could add is interbase to the list or break it up into 3 or more packages that are integrated out of the box, call it rev 2( with no rev 1 yet). here is what I see if I do that later: 1: apache/perl/modperl/dbi/dbd for all supported db and there client code/ldap client 2: open ldap/berkelydb 3: postgress 4: interbase 5: mysql ... more stuff here N: auxiliary package gcc/gmake and what ever else these components would all have to work out of the box with each other, I install 1 on my web server and 2 on my ldap box and it works or I install both on 1 box and it works. Everything should go under 1 directory /opt/something/(apache|ldap|postgress) etc. This will be a good deal of not fun work though. The way to idiot proof something is to not listen to idiots, this is where it goes and that is the end of it. Give people a list of where each default is web root, datafiles for interbase postgres openldap in a step by step pre install guide and have them start at step 1 and go to step N and you have installed the package(s) you need. marc - Original Message - From: Jimi Thompson <[EMAIL PROTECTED]> To: Marc Spitzer <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, 7. December 2000 13:40 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) > Marc, > > In order to be kind to newbie's, you will need to mention tar and gnu zip which > don't come standard on some flavors of Unix. In my case Solaris 2.6 only has > tar. Zip must be installed. Also, you are going to need to at least point them > to documentation. > > Maybe we could make extra $$$ selling tech support for your bundle (a la Red > Hat)??? The extra cabbage could go to buying ads. > > I think the goal of the "total installation" should be something akin to M$ > Office if you are aiming at the corporate/business user. PHB's like things that > they feel like they can control. > > I have no idea how you could idiot proof this, though, unless you set LOTS of > defaults. > > Marc Spitzer wrote: > > > I don't know about that, getting the correct version of perl, mod_perl. > > apache and all the preconfigured modules together and configuring cpan... as > > apposed to installing DBD::Postgres(uses XS), hell I could stick gcc > > postgres and open ldap in the package. krap I just gave my self more work. > > Here is the list so far: > > apache > > postgres > > openldap > > perl > > mod_perl > > libnet > > configure CPAN > > DBI > > DBD::CSV > > DBD:Pg > > BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs > > glibc, I think > > berkelyDB perl module > > GCC > > gmake > > > > This gives you a nice base system and everything you need to add stuff to > > it. > > > > Now I have 2 questions for the list: > > 1: is this a good idea or a waste of my time > > 2: did I forget anything > > > > marc > > > > - Original Message - > > From: barries <[EMAIL PROTECTED]> > > To: Marc Spitzer <[EMAIL PROTECTED]> > > Cc: mod_perl list <[EMAIL PROTECTED]>; Marc Spitzer <[EMAIL PROTECTED]> > > Sent: Thursday, 7. December 2000 7:12 > > Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) > > > > > On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: > > > > the only thing I would add is DBI and DBD:::CSV, > > > > > > No joins. Therefore not very useful. > > > > > > > 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. > > > > > > If you're doing that, you've graduated yourself to recompiling the whole > > > kit and kabootle. > > > > > > - Barrie > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Jimi Thompson > Web Master > L3 communications > > "It's the same thing we do every night, Pinky." > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Marc, In order to be kind to newbie's, you will need to mention tar and gnu zip which don't come standard on some flavors of Unix. In my case Solaris 2.6 only has tar. Zip must be installed. Also, you are going to need to at least point them to documentation. Maybe we could make extra $$$ selling tech support for your bundle (a la Red Hat)??? The extra cabbage could go to buying ads. I think the goal of the "total installation" should be something akin to M$ Office if you are aiming at the corporate/business user. PHB's like things that they feel like they can control. I have no idea how you could idiot proof this, though, unless you set LOTS of defaults. Marc Spitzer wrote: > I don't know about that, getting the correct version of perl, mod_perl. > apache and all the preconfigured modules together and configuring cpan... as > apposed to installing DBD::Postgres(uses XS), hell I could stick gcc > postgres and open ldap in the package. krap I just gave my self more work. > Here is the list so far: > apache > postgres > openldap > perl > mod_perl > libnet > configure CPAN > DBI > DBD::CSV > DBD:Pg > BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs > glibc, I think > berkelyDB perl module > GCC > gmake > > This gives you a nice base system and everything you need to add stuff to > it. > > Now I have 2 questions for the list: > 1: is this a good idea or a waste of my time > 2: did I forget anything > > marc > > - Original Message - > From: barries <[EMAIL PROTECTED]> > To: Marc Spitzer <[EMAIL PROTECTED]> > Cc: mod_perl list <[EMAIL PROTECTED]>; Marc Spitzer <[EMAIL PROTECTED]> > Sent: Thursday, 7. December 2000 7:12 > Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) > > > On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: > > > the only thing I would add is DBI and DBD:::CSV, > > > > No joins. Therefore not very useful. > > > > > 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. > > > > If you're doing that, you've graduated yourself to recompiling the whole > > kit and kabootle. > > > > - Barrie > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries <[EMAIL PROTECTED]> To: Marc Spitzer <[EMAIL PROTECTED]> Cc: mod_perl list <[EMAIL PROTECTED]>; Marc Spitzer <[EMAIL PROTECTED]> Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) > On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: > > the only thing I would add is DBI and DBD:::CSV, > > No joins. Therefore not very useful. > > > 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. > > If you're doing that, you've graduated yourself to recompiling the whole > kit and kabootle. > > - Barrie > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
"Aaron E. Ross" wrote: >database abstraction and connection pooling => DBI >session management => Apache::Session >load balancing => mod_backhand?? >data relational mapping => Tangram or Alzabo >templates or whatever you want to call them => HTML::Embperl/Mason/TemplateToolkit >ide => pick an editor with a few hooks to call make, install and restart I'd say that load balancing is too involved an issue to make it into a package, I'd leave it aside, as anyone actually needing it will be certainly building his apaches manually. And I would also leave the IDE aside, (although I think I have a great candidate[1]). IDEs are very personal things, and users are sometimes very attached to theirs ... so much that merely installing an IDE is sometimes an offence. [1] Having grown up in a cushioned, fancy VB 3.0 IDE, I still find both vi, emacs and textmode debug too harsh for me. So I've been toying with the early releases of Komodo (http://www.ActiveState.com/Products/Komodo.html) and I actually like it although its far from finished. Has anyone used/tested it? martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
at a time earlier than now, kevin montuori wrote: > >>> 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. Well, I see the problem, but ... when you install J2EE or WebSphere, you don't actually get DB2 or Oracle installed too. You do however, get an interface to a connection pooling mechanism, all you have to do is code it ( and maybe configure it ). I'm imagining the same thing. If you need a feature, turn it on. No CPAN, Compilation, etc ... Rather than having to install Apache::Session,DBI,DBD each time, it should be ready to go with whatever database you are using.. or not at all. Providing compiled version of DBD drivers is harder, but not necessarily in the scope of this project. Oracle provides their own jdbc drivers, not Sun and yet it is still a easier install. I agree that providing a complete working, just add water environment is impossible, but providing the groundwork for one is not. So let's start, as you suggested, with two goals 1) bundling working versions of apache and mod_perl 2) providing summaries and descriptions of mod_perl development environments. Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
At 07:12 AM 12/7/00 -0500, barries wrote: >On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: > > the only thing I would add is DBI and DBD:::CSV, > >No joins. Therefore not very useful. Actually joins are over-rated for most simple apps. It's very easy to make a calendar, address book and other common apps w/o joins. With that said though, DBD::CSV has some serious short-comings. Not the least of which is the lack of file locking. But because of the popularity of flatfile databases for newbies, that's why in our application toolkit we ended up making an abstraction that sits about more than just DBI -- native flatfiles, XML files, LDAP, SOAP, etc.. called DataSource with its own query language roughly similar in concept to Microsoft's ADO. Love it or hate it (most people who have used it do love it or hate it). > > 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. > >If you're doing that, you've graduated yourself to recompiling the whole >kit and kabootle. That's probably true. One thing that would make things much easier for mod_perl is to get the DSO mechanism fully working. A lot of ISPs compile apache with DSO support, and so making mod_perl work well with DSO would help so that you don't have to ship a pre-compiled apache. Anyway, I think people need binary distributions really. Make is too complicated for a lot of newbies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: > the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. > 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. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
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]
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]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, Aaron E. Ross wrote: > while the install and auto configure part is not very glamorous, the > possibility of being able to untar one package to get mod_perl w/ persistent > db connections, transaction management, data relational modeling/objects and > a nice templating/servlet engine is very glamorous! you could be a folk hero! > > honestly it seems like a pretty worthwhile project to me. basically, what is > missing is (cough! cough!) simply a lot of hard work. > > except for transaction management, which is apparently of questionable value, > all the pieces exist, right? > >database abstraction and connection pooling => DBI >session management=> Apache::Session >load balancing=> mod_backhand?? >data relational mapping => Tangram or Alzabo >templates or whatever you want to call them => HTML::Embperl/Mason/TemplateToolkit >ide => pick an editor with a few hooks to call make, install and restart > > granted this may not get us everything, but if we could package up the stuff > we all use over and over again, wouldn't that get us pretty far? > > Aaron > > I'm willing to contribute time to this project if given some input on how > to proceed. perhaps take a look at AO - it's a good start at a servlet engine that packages at least a few of the items you've highlighted. i'd love to participate in a project that uses AO, backhand, an o/r mapping tool, and other components to provide an out of the box 2-tier system. i'd also love to see an "enterprise" or 3-tier version of same. let's organize! i suppose i should get the AO sourceforge site up and running eh? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, Aaron E. Ross wrote: > while the install and auto configure part is not very glamorous, the > possibility of being able to untar one package to get mod_perl w/ persistent > db connections, transaction management, data relational modeling/objects and > a nice templating/servlet engine is very glamorous! you could be a folk hero! Well, while I'd like to masses to speak my name in legend and song, I've also got a lot on my plate ;) Seriously, I'm less interested in a unified package (I think Brian is working on that) than an intelligent system for doing configuration of modules/apps. For example, for one project I'm working on, I've had to do a fair amount of work to get it to try to find an existing mod_perl enabled Apache server and then to check whether or not the server is the right version of Apache and mod_perl. This kind of work would probably be useful in a more generic form. Some of this work is already in the Apache::test module, which can analyze a server and its configuration and find some useful info. Enhancing this module to really be able to give a lot of details about an existing install would be very useful. This would certainly be handy for the all in one system you describe (which is what Brian's aiming at for AO, if I'm not mistaken) but also for any other large mod_perl using app. Similarly, a mechanism for packaging tests to be done against a database would be useful (something I've worked on for Alzabo). Like I said, I really need to examine cons and see if it can help with all this. The problem being that most people don't have cons installed (although it can always be included in a package). -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
> Perhaps part of this is that we simply need smarter configure/install > methods. > ... > I've also dealt with this on another > app I'm working on (currently under NDA) that requires a bunch of modules, > a set of tables in a database, mod_perl, etc. I've been dealing w/ very similar issues in work I'm doing. I've got: * Perl modules * command line tools * database tables * data files * custom configuration * other open-source distributions and more, and it's all got to be installed in the right place, and the Right Thing has to happen if some pieces are already installed, etc. My "solution", so far, is a custom install script. Rather than trying to hack everything into MakeMaker and make it work through some deep magic, I'm writing an install script that's a layer above the MakeMaker stuff: I still let MakeMaker do its job w/ the Perl modules, regression tests, etc. But so far I've ended up writing my own code for everything else. And that's partly why it's not done yet. :) I also mean to investigate cons. bye, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
at a time earlier than now, Dave Rolsky wrote: > On Wed, 6 Dec 2000, brian moseley wrote: > > But I'd also like to point out, as Matt Sergeant said, this stuff is > _really_ hard, and not very glamorous. I would've done much less of it while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! honestly it seems like a pretty worthwhile project to me. basically, what is missing is (cough! cough!) simply a lot of hard work. except for transaction management, which is apparently of questionable value, all the pieces exist, right? database abstraction and connection pooling => DBI session management => Apache::Session load balancing => mod_backhand?? data relational mapping => Tangram or Alzabo templates or whatever you want to call them => HTML::Embperl/Mason/TemplateToolkit ide => pick an editor with a few hooks to call make, install and restart granted this may not get us everything, but if we could package up the stuff we all use over and over again, wouldn't that get us pretty far? Aaron I'm willing to contribute time to this project if given some input on how to proceed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, brian moseley wrote: > another option would be to use autoconf. wrap a configure script > around your entire set of components. allow it to find and use > whichever ones you've already got installed. have it build and install > whatever you don't already have. not very tough. also not very > portable to windows. Perhaps part of this is that we simply need smarter configure/install methods. There are many limitations imposed by the Perl MakeMaker stuff, a lot of which I have run up against trying to get Alzabo (which is part modules, part mason components, and also needs a place on disk to store info) tested and installed properly. I've also dealt with this on another app I'm working on (currently under NDA) that requires a bunch of modules, a set of tables in a database, mod_perl, etc. I keep meaning to look into cons. Perhaps that is the way to go? For example, perhaps all modules should check for the prerequisites on their own and attempt to use CPAN to fetch them if they can't find them. That works great if the person installing has already config'd the CPAN module but if not it'll ask you a lot of questions, which may be annoying. Is there a better way? I'm pretty sure there is. The problem is right now all my solutions are pretty much ad hoc (package MY up the wazoo). It would be nice to get something a lot smarter going. This is semi-offtopic but does relate the 'untar and go' concept. I don't think that that is all that likely. But 'untar, run configure, answer some questions, and go'. That would be a great goal, as opposed to 'untar, try to install, realize you're missing five pieces, install those pieces, try to install, realize you missed something else, install it, try to install once again, get it installed, tweak three config files, manually start up the server with the right switches, and go!' But I'd also like to point out, as Matt Sergeant said, this stuff is _really_ hard, and not very glamorous. I would've done much less of it except for the fact that I'm being paid to do it for the above-mentioned NDA'd project. I do it for Alzabo because I feel strongly enough about its potential to try to make it more seemless than your average Perl module/app. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
