This is an overview of what was discussed at the POE BOF, as seen from
Leolo's perspective.  Topics are out of chronological order but hopefully
grouped together better.  Also, Leolo and Uri talked a half dozen times
about POE and Stem during YAPC, so some bits are pulled in from these
discussions.  All of this is IIRC, my interpretation of what others said. 
Also, I'm missing bits for dint of not paying attention and also not having
the best memory.  Stuff with "after:" before it is stuff I'm thinking up as
a write this.  Please send all additions, corrections to poe-bof@pied.nu.




DrForr: announced the possibility of him writing a POE book this year. 
Asked whether IKC would be core by then.

Leolo: was much a-pheared by this :)  IKC needs to be split up into smaller
pieces.  cf http://pied.nu/Perl/POE-Component-IKC/FUTUR

Dhd: has already unwittingly done some of it:
publish/subscribe/unsubscribe.  

after: Maybe we need POE::Util:: for functions that any/all sessions could
use.

Uri: stated that publish/subscribe was a bad "design pattern" [didn't use
those words, though -ed].  One should have a map of what events go where and
rewrite it on the fly.

after: multi-cast events, event routing?




Joe Davidson: (?) wanted to do know if POE would help him with a problem of
to many requests coming into an app running on NT.

Uri: pointed out that Joe's app was parsing, which is CPU bound.

Sungo: remembered JobQueue and Worker sessions, that would help to keep
the work load acceptable

Uri: was stunned that POE ran on NT and reconsidered maybe putting Stem on
top of POE.



Leolo: mentioned his idea of IKC clouds

Uri: thought this was a great term



At many points: Leolo claimed to be a coward and Sungo insisted that Leolo
get his modules onto CPAN (IKC, Data::Squirrel)



All: much gnashing of teeth as to how the POE internals are... obtuse.



Uri: explained what he wants Stem to also be : a community of developers that
could be either 
    - contracted outright
    - paid after the fact via the Stem Buddies (TM) system

Also, that the bigger the community is, the bigger the contracts you can go
    after.

Leolo: is a chicken and likes small contracts. 

Schuyler: expressed surprise that while POE was Module of the Year at TPC 2,
it now seems to be Our Private Module.  

Sungo: also wants the POE community to grow.  Not just users, but
developers.  He things would should relieve the pressure on dngor (who
already works 24 hours a day) by doing doco, bug tracking/fixing, patch
repository etc.  For this we need to get some sort of access to
poe.sourceforge.mutter from dngor.

all: agreed!

DrForr: volunteered to be Documentation Pumpking for POE.  Thinks to
standardize on DocBook

Leolo: thinks a "best practices" should be drawn up.  Things like ->spawn()
for session creation, "shutdown" event to get rid of a session.

after: all stem cells have a status message that causes them to dump out
useful info about what they think they are doing.... maybe POE needs
_status?

Dhd: said that he's having a hard time getting his sessions to close down.

Leolo: grumped about how POE doesn't have enough debug info to make adding
this feature easy, having added it to IKC.  

Sungo: I've done some debugging stuff that allows you to follow the data
flow, event -> event -> event.

Leolo: thinks output from this could be used to create a "big picture" that
would help in grokking 



All: 
Some folks showed up and we waved our hands around and explained that POE
totally rules.  I don't know if we impressed them :)



Sungo: wanted an easy way for IKC to dump out all it knows about published
events and subscriptions and remote kernels.  

Leolo: wanted to be studly and implement this on the spot, but sungo's
laptop didn't have Joe on it. :(



Leolo dumped many ideas :

Leolo: "exceptions"... session Foo wants to know if anything bad happens to
session Bar.  This is an extension of IKC's monitoring.

Sungo: really likes the monitoring.  Much joy for auto-discovery.

Uri: you could do that with the logging feature in stem

Sungo: you need to overload invoke_state.

after: or look at this as another case of event routing

Leolo: grumped that sky has code that would be useful here, but that isn't
available.





Leolo: scripting.  event1->event2->[event3,event4,event5]->event6.  If we
could do this, we could also build up a rollback script as we are doing a
transaction.

Uri: had a divergent view on this.  can't recall what it was.

Leolo: had another way of looking at it.   Think of it as outside request
coming in (app server example) and this means a "tree" of other events is
"sparked".  If something goes wrong, you have to make sure a response goes
back at some point.  So 2 things : you have to track all events that are
"children" of the first request and allow certain events to detach from this
tree.

Uri: use a timeout instead.

Leolo: icke.  Also, doesn't really solve the problem.




Leolo: rollback  

Uri: very hard to get right

Leolo: ick.  good thing it's not critical to my app.

Leolo: don't think it of as persistence, think of it as object lifetime.  Ask
each object (note hand-waving about object means here) at various points in
the applications run time if they still want to be saved.

Uri: no, just set a flag somewhere in the object's config

Leolo: but that's nearly the exact same thing.... though maybe a bit more
efficient.



Leolo: don't do HTML!  Use widgets.  Add validation info to the widgets,
save them until the request comes back and use it to validate the input. 
There is a web widgets group discussing this actively.



Leolo: once did a draft of POE interface descriptions.
http://pied.nu/Perl/POE-Interface/example.interface
http://pied.nu/Perl/POE-Interface-0.01.tar.gz
(note: uses XML.  much pain)

Sungo: would like to see this implemented.