On Thursday, February 14, 2002, at 10:22 PM, Stephen Adkins wrote: > Some have recently suggested that more analysis was needed > in the definition of what we are trying to build in P5EE. > > This is true, and it is ongoing. > More analysis requires > descriptions of resulting systems. Some of these have > been described in the Applications page.
Hmm, this isn't meant as a rant, or a complaint, or anything else, its just a (probably ill-considered) reaction to what I'm seeing on this list. I think this was what Greg was saying as well, but I don't want to put words in his mouth, so I'll claim them as my own instead :-) I've been following p5ee for a while but not saying much because everyone seemed to be going great guns and getting things done. However it seems to me that 1 (one) person needs to take responsibility for each area of the architectural elements that live in all of these generalized applications (for example object persistency) and define a lowest common denominator interface. For example, object storage needs to be able to store(), load() and delete() objects (and perhaps this could be made a bit more complex, and define a constructor as well -- how does new() sound?). What happens behind these interfaces is for the most part meaningless, as long as it does whatever it does reliably. Implementations may place additional functionality on top of these basics, which is fine, but not needed for matching the p5ee definition. Perhaps it could be taken one step further and a test suite for each of the architectural elements could be written. It just seems that the quickest route to getting an implementation out of the door is defining a simple set of interfaces rather than a complex set of semantics and one or more implementations. CPAN has a lot of crap (I'm responsible for some of it) and a lot of good. Like Greg said, once a *simple* interface is decided, wrappers can be written and software can be shipped. Regards, James.
