On Fri, Aug 06, 2004 at 08:11:19AM -0600, Chris Fedde wrote: > On Thu, 5 Aug 2004 23:35:36 -0400 Rocco Caputo wrote: > +------------------ > | So, is it worth it? Does anyone have other reasons for or against it? > +------------------ > > OK. Let me see if I have the state of this discussion: > > - Namespace issues seem to be of some interest. > PoCo vs POE::Server/Client vs POEx vs POX
POEt, and Potato (These Are Third-party Objects) were some other suggestions I've heard. I don't think they were serious, though. > - No consensus on instantiator name. > spawn, create, new, other? At one point, Philip Gwyn suggested on IRC that we use create() for sessions, new() for objects, and spawn() for components. So we have at least one vote for a naming scheme rather than a single name. > - No consensus on 'Wheel-like' vs 'Session-like' like vs 'write-these-handlers' > vs POE::Compoment::Server::SMTP like. > You're a creative lot. I suspect that there are other interface > catagories too. Each has its strong and weak points. Whatever's decided upon should probably support some kind of inheritance, though. People like to extend things by subclassing and overriding. > - Some people think that a base class that provides some infrastructure > would be a good idea. But no one has assertted what that would look > like. > > - No clear statement for needs yet: > What do programmers want from a POE component? > Why would a consistant interface to POE::Compoents be a good thing? > Are we trying to lump things that are different into the same bucket? Pinning down what people need is probably the hardest and most important question you've asked. Once it's done, though, the rest of your points should almost answer themselves. I'm hoping for a few things, but I won't be disappointed if something better actually happens. - A standard class to encapsulate messages passed between components. It would be slower than passing around unadorned hashes and lists, but it can enforce whatever policies that come up in the standards discussions. - A standard "component" class that encapsulates most of POE::Kernel as well as additional features people need. From the component interface's point of view, there would be no POE::Kernel or POE::Session. Just a happy soup of components passing messages between themselves. - A backdoor into the low-level POE::Kernel and POE::Session guts, so people can drop down into lower-level code when necessary. Happyfun component love is all nice-nice, but sometimes people need to get their hands dirty. Component writers, especially. - Probably other things that haven't come to mind yet. > Did I get most of it? Only time will tell. :) -- Rocco Caputo - http://poe.perl.org/