Hi, John! In addition to proposed .war I would consider also dynamic bootstrapping. Two important advantages Perl has is CPAN and automated tests. CPAN approach can be considered as alternative to gzip/tar packaging. Every application knows what modules it uses. Why don't load those on startup and cache on disk only if necessary? It can be done on web/app server startup. Only modules that are not available will be checked in repository. There are a couple of things that need to be improved though. I should be able to bring up CPAN-like repository easily and configure to search it first before searching CPAN archives. I should be able also to query specific version (not just older than). Bundles may need to be signed to be trusted.
There are many aspects we want to address with p5ee: consistent API (across modules and domains), modules selection, stable versions and module interoperability, packaging, marketing, politics, and others. I don't think that API wrappers will work in most cases. If we combine components that Gunther and John proposed (I added a few) we'll get a pretty long list: Messaging Authentication/Identification Sessions Webservices Security Database Access Auditing/Logging Exception and Error tracking Workflow Management Configuration Internationalization Transactions Directory Testing Deployment Documentation Every groups should have an API, list of modules and interoperate nicely with others. As the first step we should probably agree on components and check which of them are covered by modules and where we have a choice. API question is the tricky one. Messaging API allows you to send async requests. SOAP (as a protocol) has also capabilities to send async messages. Should it mimic messaging API or have its own? Best wishes, Paul. --- John Napiorkowski <[EMAIL PROTECTED]> wrote: > Since perl can output byte code, perhaps this could be a good > method for > combining the apps in the way you suggest? We could create a > convention for > directories (for xml, xslt templates, perl code) combine the code > and gzip/tar > all the files together. We'd then need to create an Apache module > that knows > what to do when it sees that file, and maybe some way to cache the > results so it > doesn't need to uncompress the file each time. > > Peace, or Not? __John > > Michael A Nachbaur wrote: > > > My discussion probably has nothing to do with what everyone > thinks P5EE > > entails, but it is something that I see is very important. My > main interest > > in perl is in the area of web development and deployment. While > I love the > > flexibility mod_perl gives me, packaging and configuring a > complex site is > > tedious. Now imagine if we have failover and loadbalancing > functionality in > > P5EE, how much more complex will the configuration of each > web/app server > > be? > > > > I'd really like to see the support of ".war"-like bundles under > > mod_perl/Apache. For those of you unfamiliar with Java app > servers, a .war > > file is like a .jar file, except for web applications. It > bundles the > > configuration, libraries needed, classes and HTTP resources for > the site. > > You deploy that application, or site, on a server by dropping the > .war file > > in a directory. > > > > Now, this probably is more of a mod_perl change than a P5EE > change, but I > > wanted to toss my USD$0.02 in here, since I know CIOs won't want > to worry > > about configuration differences between application servers. > > > > -man > > Michael A Nachbaur > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
