Front page | perl.p5ee |
Postings from September 2002
At 06:36 PM 9/23/2002 +0100, Greg McCarroll wrote: >* Stephen Adkins (stephen.adkins@officevision.com) wrote: >> At 12:57 PM 9/20/2002 -0400, Stephen Adkins wrote: .... >I'm not sure that smaller focused groups are the way to bring about >P5EE. First of all I believe that Perl already has P5EE it just needs >a light layer ontop of many CPAN modules and a bit of marketting. Now >while it may seem like a good idea to split each of these layer >writing groups into seperate groups there will be so little work to do >in each layer group (if they are writing functional code that isn't >simply doing wrapping then they will only muddy the waters of P5EE) >and they are going to face a lot of similar issues such as how you >reflect level of compliance of implementation modules. It is far from simple to: * document an enterprise application architecture for enterprise systems written in perl using existing CPAN modules (there are hundreds of design decisions to be made even after modules are selected) * write glue code that ties it all together * support and receive feedback from a user community to tune and evolve this architecture If you think differently, I would guess it is simply that you have a different goal in mind of what should be accomplished than I do. For instance, I could easily say, "This is P5EE" * Apache/mod_perl - web application container and SOAP container * Template-Toolkit - web user interface template engine * Alzabo - RDBMS access on top of DBI So... * What about other web servers? (IIS? Netscape? ...?) * What about non-web-based clients? * What about information not stored in relational databases? The enterprise application architecture I envision will support clients on any and every platform in the enterprise, and web applications implementable on all of the specified platforms. http://www.officevision.com/pub/p5ee/platform.html It will describe how and to what extent the architecture can support all of the specified enterprise requirements. http://www.officevision.com/pub/p5ee/definitions.html Individuals and companies have solved these issues sufficiently for their particular applications. Where is the description of the generalized framework? If this were simple it would have been done by now. >However I realise we may have different views on this, so if you disagree >lets discuss this ... > >What do you think that can be achieved in smaller groups that can't be >achieved in this group. What problem(s) do you think the smaller >groups fix that this group has? I'd appreciate a one or two paragraph >answer on this. I think a more appropriate question is * What (at all!) can be done in a single, large group? So here's the brief answer to your question. Q. What problem(s) do you think the smaller groups fix? A. Smaller groups can reach the level of unity necessary to get something (anything!) done. The longer answer follows. I make the following observations. * The perl community is highly fragmented, with many good solutions to nearly the same problems. And people have loyalties to those solutions because they know them and have invested their time and energies in them. * There is not a single source that I have ever found for how to write enterprise applications in perl. The focus is on modules and small distributions, not how to integrate them into a system with enterprise-quality attributes. * A working piece of code or an existing piece of documentation (albeit with limitations or imperfections) goes a lot further than the most grandiose theory created in committee. In light of this, I proposed about a year ago that the people who know most how to do enterprise application development write up competing specs of how to do it. In general the reaction to this was that it would be more desirable to have a single set of code that we could all agree on. Although I agree that this would be nice, I have always believed that it would be competition among reasonable alternatives that would bring any winner to light. So the consensus was to work for a common code base. People on this list engaged in much discussion about what enterprise application development was and what the good modules were and I catalogued those (albeit imperfectly) in my Components page. http://www.officevision.com/pub/p5ee/components.html Then I set out to create a framework that would make the most people happy by providing flexibility to use whatever template system or persistence engine or configuration file format they chose. No one was happy with it. This approach could not really get any kind of ringing endorsement to move it into the P5EE namespace. (Even though it did get a majority of votes, the dissent was significant enough to signal that the people on the list are not ready for any kind of common code base. It must be proven in implementation first.) So I conclude that the most that we (as a group) are ready for is a shared discussion area. But some of us are ready to move beyond that. The fact is we are already many small groups (individuals, in fact). Discussion on the list has already shown that there is insufficient unity of purpose or direction to achieve what most of us wish someone would do. Suppression of small groups forming is to inhibit the progression of thought toward our goal of One P5EE (if that is even ever attainable). I intend to make this project support whatever size groups will be effective in achieving the advancement of enterprise perl. >> I'll be proceeding with >> this plan and recasting the P5EE web site in this new light of >> "P5EE diversity". > >I hope you after this email you'll take time to discuss the matter >first. This plan is the result of all of your input. It is the logical conclusion of discussions and votes. No other plan has emerged that will get us going. Anyone who wants any other outcome suggest a better plan and be prepared to get involved to work that plan. StephenThread Previous