At 12:08 AM 10/30/2001, Stephen Adkins wrote: >At 05:36 PM 10/28/2001 +0200, Robin Berjon wrote: > >On Sunday 28 October 2001 15:58, Gunther Birznieks wrote: > >> I think the list is basically reasonable. Although I think that template > >> systems is tough to put into the P5EE category. It is in J2EE because of > >> JSPs so tightly coupled to servlets. But with the numerous template > >> technologies out there for Perl, I would prefer to put it into it's own > >> category -- perhaps within interfaces. > > > >Imho templating systems have to be out of P5EE if only for political > reasons > >:) We all know for a fact that as soon as we're going to try to fit one > into > >the framework no one is ever going to agree on which one to choose, and > P5EE > >will split into tiny bits and die in flamewar. > > > >Hi, > >This thread of discussion has caused me to reflect on two emerging visions >of what the P5EE is all about. > >My vision of P5EE is expansive and diverse rather than >the limited and standardized vision seemingly held by Robin, Gunther, >and Paul. > >I propose that we can accommodate both visions if we can develop the right >vocabulary. > >My vision is consistent with the view that the mission of the P5EE is >generally > > to promote the development, deployment, and acceptance of > Enterprise Systems written in Perl > >I think the following two elements support this mission. > > * Expansive - specify everything possible that presents a consistent > Enterprise Perl Architecture rather than limiting the P5EE > recommendations to a limited set of politically acceptable choices. > i.e. specify a template system, a persistence layer, etc. > This will include many decisions which make up one great way > to do Enterprise Perl Development without having to be the > "only way" or the "standard way". This will be helpful to people > wishing to develop Enterprise Perl Systems.
Well, I guess it depends. I feel that if we make it too expansive it will also be confusing. Imagine if all the Java vendor code that exists on top of J2EE were made part of the J2EE standard? J2EE would be massive as well. But I don't think it would necessarily help Java because it would be confusing and difficult to wade through the knowledge just as it is confusing and difficult to wade through (right now) just figuring out template systems alone. Perrin did a good job on the templating front, but I also think it's not necessarily a huge comprehensive paper yet and then to have to do that with all "optional" elements of P5EE would just be such a massive project. > * Diverse - The only way to be Expansive and not "exclusive" is to > accommodate a diverse set of views on what the full enterprise stack > looks like. > >The opposing two elements are: > > * Standardized - specify only what components that everyone can agree on > * Limited - the result becomes a subset of even what J2EE proposes, which > in my opinion, is far short of the support we could provide to > Enterprise Perl Development. > >Now some have suggested (Gunther?) that we distinguish between (1) what is >a part of P5EE, and (2) what is P5EE-enabled. This may be semantically >equivalent to saying that the "Limited/Standardized" vision is a subset >(perhaps growing over time) of the "Expansive/Diverse" vision. > >However, this seems to indicate that the "Expansive/Diverse" vision does not >have a place under the aegis of "P5EE" or in the P5EE effort. >This, to me, is why the discussion of P5EE's mission is so important. >It resolves questions like this. And the mission I am operating under >(because no one has proposed any other mission statement or given >compelling reasoning for it) leads me to believe that an Expansive/Diverse >vision is appropriate because it would be helpful "to promote the >development, deployment, and acceptance of Enterprise Systems written in >Perl". While I understand you think it would help the cause to include everything, I think it would have the opposite effect. * By making the effort too large and less likely to get done (at least in a phase 1 approach) * By diluting what "enterprise" means to the point that it loses branding * By not making it less orthogonal to Java and thus confusing people who we might bring over to the Perl camp (eg Java interoperability with Perl) * By making the documentation so large that it is difficult to wade through and understand instead of being more lightweight and merely referencing other documents that are not directly part of the P5EE effort I guess to me the issue is partially that an expansive effort is quite resource hungry and time consuming. But this is not really it because that could be solved by a "phased approach". But I am not sure an expansive effort is what there should be in the end. That is, it's also that I am not sure that it is the best way to make the effort really be easily absorbed by new people coming into Perl and wanting to know the best way to answer or hook their Perl systems into systems offered by J2EE or similar architectures. This is the classic marketing irony. You think that by encompassing everything, you do a service because after all "Who wouldn't want everything for the same price", but it also stands to backfire as people like to deal with information in nice clean chunks. I happen to believe templating by itself in Perl is such a large and complex topic that it is a good "chunk" by itself that should be referenced by P5EE but not directly included. It's not just because of politics (whose templating system gets included) but rather one of making these things chunkable and hence marketable. I guess one major requirement should be the marketability of P5EE. I believe the advantages of keeping it simple are * Easy to grasp the concept because it's simpler * Orthogonal (as much as makes sense) to J2EE making it very easy to cross train Perl to a Java person * Easy for other efforts to evangelize P5EE because instead of being engulfed, they become cross linkers of P5EE * Other efforts may come and go, but their success or failure will not affect P5EE because it won't become a matter of a whole subsection dying and then being replaced (nor not). So the longevity of the P5EE will make it seem more stable which is helpful for people in Enterprises. * The other efforts will be easier for people to find because they will be independent efforts (eg someone does a search looking up the best templating system they don't have to wade through P5EE or get confused)... The above issues to me have to do as much with keeping the level of effort needed lower as making P5EE more capable of being grasped or marketable. I don't think marketing is an evil term (I was blasted by someone a few days ago privately for "giving in" to marketing terms etc...) I don't see marketing being evil. Marketing is a means of figuring out the best way of spreading information to the most amount of people possible and in the way that you want them to learn it. To some degree, I see this list being a marketing tool for Perl to evangelize itself. To simply and surgically, be able to point anyone who think Perl is not for the enterprise to p5ee list and subsequent documentation and say "here are the case studies as blueprints for a p5ee app"... >I propose that both of these visions are compatible with some vocabulary >such as the following. > > * P5EE - any extensions (doc+code) that promote the development, > deployment, and acceptance of Enterprise Systems written in Perl > (i.e. the P5EE aegis covers both of the following) > * P5EE Core Modules - (Limited/Standardized vision) the set of core > modules widely agreed on my Enterprise Perl Developers that are a > part of Enterprise Perl Systems. > * P5EE Blueprints - (Expansive/Diverse vision) (note the parallel to the > concept of the J2EE Blueprint, http://java.sun.com/j2ee/download.html) > Details describing good ways of implementing Enterprise Perl Systems > on top of P5EE Core Modules. (May include many more details than > are strictly relevant to Perl.) > * P5EE Optional Modules - (bridge between the two) sets of modules > which are part P5EE Blueprints which are beyond the P5EE Core Modules. Tentatively I think this is reasonable... Which of the above would be the equivalent of P5EE-Enabled that I mentioned before and that you referenced above?
