At 01:59 AM 10/26/2001, Stephen Adkins wrote:
>At 10:31 PM 10/25/2001 +0800, Gunther Birznieks wrote:
> >I like Ajit's recommendation, the RFC (along with a framework like
> >Stephan's) to allow some brainstorming.
>...
> >This is why I view P5EE as a multistep process with the following
>milestones...
> >
> >1) Identify Enterprise APIs (Brainstorm)
> >2) RFC Them
> >3) Map them to current modules
> >4) Document them as one whole helper document about how to find a solution
> >to X enterprise problem (following the API list basically)
> >5) Identify Applications and Frameworks that use the modules identified in
> >3 and label them as P5EE Enabled. These frameworks would explicitly be
> >documented in case people want to see these APIs in use.
> >6) Then take a step back, look at the APIs and identify which ones would
> >benefit from standardization (mail is one)
> >7) Standardize it
> >8) Redocument
> >9) Rinse, Repeat.... #6
> >6-9 will take a long time ... possibly forever. So don't hold your
> >breath.... but it will come slowly.
> >10) In parallel for 6-9, should be initiatives where people say "wouldn't
> >it be cool to do X for the p5ee initiatve" and they will do it. eg JAAS or
> >a personalization API comes to mind.
> >11) Document
> >12) Rinse, Repeat #10.
>
>Hi,
>
>Out of all of the brainstorming to identify "Enterprise API's" (1), I am
>compiling them as a laundry list. We have not yet RFC'ed them (2), but
>based on an estimate of what they are, I have begun to map them (3) to perl
>modules in the proposed Perl SDK and elsewhere. My progress continues to
>be documented at
>
> http://www.officevision.com/pub/p5ee/p5ee_modules.html
>
>As far as I can tell, we haven't really done anything like steps 4-12.
>
>In order to proceed, I would like to get some discussion from the community:
>
> * Do we expect to get a single P5EE *standard* out of this effort?
>
>Or is this P5EE mailing list a forum for enterprise developers which will
>support multiple (perhaps converging) P5EE specifications?
>
>I believe that the latter (multiple competing/converging specs) is the
>only realistic expectation. (Just think of the fallout that will occur
>when we try to "standardize" on a Templating system or a
>Persistence Framework. "Standardization" will only occur as one of the
>competing specs gains favor by demonstrating its effectiveness.
There is no real requirement for fallout anyway if the P5EE mission is to
be reached. So it's good that there is a lot of brainstorming of a huge
list of modules and APIs, but keep in mind that even J2EE recognizes that
only a few things belong in J2EE.
The things that belong in J2EE are things that provide code to achieve a
well-accepted framework API. Even persistence engines and templates are not
considered part of J2EE except of JSP (to copy ASP basically). I think we
should reference templates and persistence frameworks that are P5EE-Enabled
as the next step the same as application frameworks.
P5EE should be about getting a good solid minimum API that basically
doesn't attempt to do too much more than J2EE. At some point I believe it
is good for Perl if we throw away diversity for some key core APIs, but we
should, as much as possible, promote diversity that is part of Perl's core.
Application-level frameworks is where I would draw the line and say that I
expect as much competition as possible.
Even in Java, there are 100,000 object persistence engines (one for every
Java developer :) ). They all hook into J2EE but they aren't part of the
J2EE spec.
>I think we need to reach consensus on this (i.e. the mission of this
>list) before we can make much progress as a community.
This is likely true, and as usual I will advocate minimalism as much as
possible. :) But with enough work that it is a worthwhile effort.
Later,
Gunther
