Home > Archive > PERL POE > June 2007 > POE Hackathon at YAPC::EU Vienna 2007
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
POE Hackathon at YAPC::EU Vienna 2007
|
|
| Kidney Bingos 2007-05-30, 8:16 am |
| The YAPC::EU 2007 organisers have kindly agreed to a POE Hackathon at this years
conference in Vienna.
http://vienna.yapceurope.org/ye2007/talk/678
So, dear fellow POEvangelists, I am now on the hunt for possible things that
can be hacked on.
Bearing in mind that some of this will be determined by the audience on theactual
day, what kind of things should we be hacking on?
Is there something long outstanding that you would like done ? A PoCo, wheel or filter ?
More recipes for the POE Cookbook ? <http://poe.perl.org/?POE_Cookbook>
Any ideas would be warmly welcomed.
Many thanks,
--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk
==========================
| |
| Jordan Coleman 2007-05-30, 7:20 pm |
| On May 30, 2007, at 8:15 AM, Kidney Bingos wrote:
> So, dear fellow POEvangelists, I am now on the hunt for possible
> things that
> can be hacked on.
I may be the only one interested in this, but I'd love to see
something that gives POE a simple paradigm for message passing and
dispatching between sessions, similar to Uri Guttman's Stem framework.
I'm not terribly familiar with Stem myself, but from what I've
gleaned, one of its big features is you can very easily create a
session (a "cell" in Stem lingo) that accepts an incoming message by
declaring within that session a sub named with a certain convention.
Stem has some underlying registration and dispatching so that you can
plug cells together into an application and set up the message
mapping between them. It's a very slick convention, very much in the
style of Catalyst's controller actions.
Again, I'm far from an expert on Stem, so someone else may need to
clarify (or dismiss) what I'm talking about here, but I just can't
help but think about the value of having Stem's message passing
concept combined with all of POE's capabilities and library of
components, wheels, etc.
++Jordan
| |
| Rocco Caputo 2007-05-30, 7:20 pm |
| On May 30, 2007, at 13:40, Jordan Coleman wrote:
> On May 30, 2007, at 8:15 AM, Kidney Bingos wrote:
>
>
> I may be the only one interested in this, but I'd love to see
> something that gives POE a simple paradigm for message passing and
> dispatching between sessions, similar to Uri Guttman's Stem framework.
>
> I'm not terribly familiar with Stem myself, but from what I've
> gleaned, one of its big features is you can very easily create a
> session (a "cell" in Stem lingo) that accepts an incoming message
> by declaring within that session a sub named with a certain
> convention. Stem has some underlying registration and dispatching
> so that you can plug cells together into an application and set up
> the message mapping between them. It's a very slick convention,
> very much in the style of Catalyst's controller actions.
>
> Again, I'm far from an expert on Stem, so someone else may need to
> clarify (or dismiss) what I'm talking about here, but I just can't
> help but think about the value of having Stem's message passing
> concept combined with all of POE's capabilities and library of
> components, wheels, etc.
This sounds a lot like POE::Stage. See CPAN, where a developer alpha
has been lurking for a while. It's a formal version of POE's
stronger design patterns, and it's my personal vision for POE's
future. It's most fundamental ideas are:
1. Request and response messages are like asynchronous method calls
and returns. There is a request tree rather than a call stack.
2. Messages have associated variable scopes. This is a side effect
of requests behaving like method calls. These scopes may persist
over the course of many calls, as long as the message is still active.
3. Responses are typed, and the caller maps response types to
callbacks. This is done within requests rather than at the Session
level. Stages are more loosely coupled than components or sessions.
4. There is lexical magic inherent in the naming of things. A lot of
this is derived from discussions with Catalyst people in irc.perl.org
#poe (hi, Matt). Also see Lexical::Persistence, which was released
as an offshoot of POE::Stage.
Sample code? Here's a working "Hello, World" from the synopsis:
http://thirdlobe.com/projects/poe-s...k/examples/poe-
stage-synopsis.perl
Other, more involved examples are in the same directory. This one
illustrates many of the fundamental ideas:
http://thirdlobe.com/projects/poe-s...trunk/examples/
01_basics.perl
If the hackathon's going to tackle this, there are two main things to
be done. They're widely-scoped, but they can be dealt with in pieces:
1. Flesh out the basics. POE::Stage should do at least as much as
POE's basic wheels and components. Things that rely on optional
dependencies (Tk, Curses, etc.) aren't necessary.
2. The paradigm may be flawed, especially around the edge cases.
Identify and catalog the issues. If possible, and time permitting,
fix them.
I think this is a highly worthy project, and I suspect that not
enough people know about it.
I'll be happy to answer questions about the project. Please direct
them to the list.
Anyone who wants to work on the project (hackathon or not) should
send private e-mail with a user name and password, generated by
running htpasswd -ns $username. I'll set you up with repository access.
Thanks!
--
Rocco Caputo - rcaputo@pobox.com
| |
| Rocco Caputo 2007-05-30, 7:20 pm |
| On May 30, 2007, at 13:40, Jordan Coleman wrote:
> On May 30, 2007, at 8:15 AM, Kidney Bingos wrote:
>
>
> I may be the only one interested in this, but I'd love to see
> something that gives POE a simple paradigm for message passing and
> dispatching between sessions, similar to Uri Guttman's Stem framework.
>
> I'm not terribly familiar with Stem myself, but from what I've
> gleaned, one of its big features is you can very easily create a
> session (a "cell" in Stem lingo) that accepts an incoming message
> by declaring within that session a sub named with a certain
> convention. Stem has some underlying registration and dispatching
> so that you can plug cells together into an application and set up
> the message mapping between them. It's a very slick convention,
> very much in the style of Catalyst's controller actions.
>
> Again, I'm far from an expert on Stem, so someone else may need to
> clarify (or dismiss) what I'm talking about here, but I just can't
> help but think about the value of having Stem's message passing
> concept combined with all of POE's capabilities and library of
> components, wheels, etc.
This sounds a lot like POE::Stage. See CPAN, where a developer alpha
has been lurking for a while. It's a formal version of POE's
stronger design patterns, and it's my personal vision for POE's
future. It's most fundamental ideas are:
1. Request and response messages are like asynchronous method calls
and returns. There is a request tree rather than a call stack.
2. Messages have associated variable scopes. This is a side effect
of requests behaving like method calls. These scopes may persist
over the course of many calls, as long as the message is still active.
3. Responses are typed, and the caller maps response types to
callbacks. This is done within requests rather than at the Session
level. Stages are more loosely coupled than components or sessions.
4. There is lexical magic inherent in the naming of things. A lot of
this is derived from discussions with Catalyst people in irc.perl.org
#poe (hi, Matt). Also see Lexical::Persistence, which was released
as an offshoot of POE::Stage.
Sample code? Here's a working "Hello, World" from the synopsis:
http://thirdlobe.com/projects/poe-s...k/examples/poe-
stage-synopsis.perl
Other, more involved examples are in the same directory. This one
illustrates many of the fundamental ideas:
http://thirdlobe.com/projects/poe-s...trunk/examples/
01_basics.perl
If the hackathon's going to tackle this, there are two main things to
be done. They're widely-scoped, but they can be dealt with in pieces:
1. Flesh out the basics. POE::Stage should do at least as much as
POE's basic wheels and components. Things that rely on optional
dependencies (Tk, Curses, etc.) aren't necessary.
2. The paradigm may be flawed, especially around the edge cases.
Identify and catalog the issues. If possible, and time permitting,
fix them.
I think this is a highly worthy project, and I suspect that not
enough people know about it.
I'll be happy to answer questions about the project. Please direct
them to the list.
Anyone who wants to work on the project (hackathon or not) should
send private e-mail with a user name and password, generated by
running htpasswd -ns $username. I'll set you up with repository access.
Thanks!
--
Rocco Caputo - rcaputo@pobox.com
| |
|
|
|
|
|
|
|
|
|
|
|
|
|