Nigel Hamilton <[EMAIL PROTECTED]> wrote: > Would such a standard (albeit optional) be useful for mod_perl2?
I don't think so. Let me explain a bit. <opinion> Over time, the modules on CPAN have become higher level and more complex, almost resembling applications in their own right. Yet they are moduler and useful in applications. This even goes for such modules as HTML::Mason and AxKit. They seem like applications in some ways, but they are useful components in others (hmm... application/component duality). I'd like to see what we will build out of the applications we are building today. The problem with traditional applications is that they resist being used as libraries. This is the beauty of writing modules for CPAN -- it forces a person to think in terms of libraries. Similarly, it is natural for us to have several different applications at the top of the heap that we can choose from and (on CPAN) use them to build new applications. Perhaps we can take a couple of frameworks and duct-tape them together in a new and wonderful way that has never been done before because no other environment allowed it before. I don't know why someone would, but that doesn't mean we should keep them from doing it. As soon as we point to something and say `This is the one' we have just said that we don't think the rest should be encouraged (or are not as good as The One). As soon as we are not encouraging, we are discouraging. At that point, we have cut off the vitality that makes the perl (and mod_perl) community so rich. This is a bit rambling and I'm not sure how to tighten it quickly. </opinion> My vote is to let mod_perl do what it does best, interfacing with Apache, and leave the rest to CPAN. No telling what will grow there. > Generally standards run contrary to the TMTOWTDI approach of Perl >but there are some advantages in a 'minimal' mod_perl web application >standard: > >* ISP's could install mod_perl applications in a uniform/consistent way - >(e.g., the standard should prevent name space collisions etc.) > >* A subset of mod_perl methods could be selected as a basis for the >standard allowing other 'container' servers besides Apache (e.g., like >http://jetty.mortbay.org - except in Perl not Java) Not sure I understand this part -- currently mod_perl only runs with Apache. imho (and feel free to flame me in private) the only useful production system such as what you are talking about will be under mod_perl (assuming it is written in Perl). >* Software companies (not sure who) could provide >replication/clustered/load balanced solutions based on this standard As long as the core is written to withstand running on a web farm, this will be trivial. Of course, that means the non-trivial parts are in the core :/ The best I've been able to come up with (in design at this point) is a system that is aware it is on a web farm, but does not itself handle load balancing. I am letting a switch (from F5) handle some of that and might be looking at mod_backhand. Those are the tools that are built for doing it. There's even whakamole for making sure IP addresses are available (a sort of poor man's load balancing switch if used in conjunction with DNS round robin). >* Application configuration/management tools could be used to administer >mod_perl application(s) on the same server(s) This could be done with a properly written Apache config file and a few web pages. >* We could share 'mod_perl' applications on CPAN more easily/quickly > > Ideally, I'd like to download a single mod_perl archive file >(e.g., application.mod) place it in a 'standard' application directory and >then point my browser to the new application. Take a look at Uttu (http://uttu.tamu.edu). It has (or is supposed to have) the capability of bundling all the perl modules, pages, and misc. files into a single tarball that can be installed using the CPAN shell. There are probably bugs since it is still pretty much alpha/pre-beta code. Uttu also handles name spaces for HTML::Mason applications by assigning a default package (instead of HTML::Mason::Commands) that is based on the virtual host and root location. I'm not sure if this is the same namespace issue mentioned in the first point above. I'm in the middle of writing a design document for a framework that allows arbitrary mapping of urls to files, on-the-fly server reconfiguration using a front-end proxy and back-end app. server, and web-based management of views. It also is built to work in an HA environment, keeping track of which systems are up and down (and thus available for it to use, or so it knows which parts of the website to make unavailable). It will be scalable since it will work in a web farm. Plus quite a bit more. Almost all of this will be installable via the CPAN shell :) I'll post a url for that document when it is compeleted (sometime this summer [or winter for the southern hemisphere]). -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
