Hi, Good points.
If you are volunteering, you are invited to continue this thread. If you are just hoping that your comments will motivate others to volunteer, your comments are still welcome. Fundamentally, the only way that the project will move any faster is as people volunteer. There are two ways to volunteer at the moment. 1. Sketch out your own vision of P5EE in your own experimental namespace 2. Join someone else in their experimental namespace The P5EEx::Blue namespace is progressing at a pace commensurate with my interest and availability. In some limited ways, it is ready for others to begin participating if they would like (as I mentioned in my response to the Spread::Queue message). So if anyone would like to do what you describe in the P5EEx::Blue namespace: they are welcome to. (i.e. Take an area and define the standard interface and perhaps develop one or more implementations.) http://www.officevision.com/pub/p5ee/software/htdocs/api/ In particular, I would welcome definers/contributors/maintainers for P5EEx::Blue::Messaging P5EEx::Blue::Procedure P5EEx::Blue::LogChannel P5EEx::Blue::Security P5EEx::Blue::TemplateEngine Stephen At 10:33 AM 2/15/2002 +0000, James A Duncan wrote: > >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. > > >
