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/

Reply via email to