On Fri, Aug 03, 2001 at 10:17:07AM -0400, Matt Cashner wrote:
> On (08/03/01 09:50), Rocco Caputo wrote:
>
> > > Up to now using POE is kind of "raw". Building systems that are secure
> > > by default should be easier if applications are written on a more abstract
> > > level.
> >
> > I have mixed feelings about this. SSH (and SSL) can be add-ons, just
> > as the Wheel classes should be in a separate distribution and included
> > by bundle.
>
> i dont ever want the raw-ness to go away. give me ways to hide it for a
> while when i'm feeling lazy :) or ways to build on nifty things like
> ssl. but a lot of the times i wany very raw base code. i'm mostly a bare
> metal kinda guy.
of course it should stay accessible. but POE will be most useful when
bigger applications can build on top of it.
but as you have to split normal programs into non-blocking pieces to make
it work with POE, this is not as easy anyway. imagine you would want to do
print A()+B(); in POE and A and B would take time and are independet tasks.
using raw code you would end up in posting events to both (the function
call part). then you would write to new handlers receiving the result
events. you would need a state that holds the amount of results you got
so far. raw code is _not_ useful for this.
to my mind this is a big problem that we will have to deal with until
threading becomes stable or the interruptible functions in perl6 can be used
for this. normal coders/scripters are used to writing non-concurrent
programs. we will have to make the entry barrier to POE as low as possible
and hope that these people will start to like concurrency, and the different
methods that fit this aspect better.
i'm not gonna start talking about session/object addressing again ... :)
in the last days i made some plan for a POE::Script module. Actually
it should be POE::Script::something but i don't have a name for it yet ...
it will be based on perl functions (subs or eval'd strings) that must not
take time (or just a bit, non blocking as the usual POE event handler).
they receive and output a set of named parameters. they don't _need_ to
know anything about POE but can be full POE handlers.
post and prepocessing of values (or deciding what is returned anyway) is
done by pushing values or a function combination on the stack, no new
syntax, specified similar to functional programming.
there is one stack for one call, so the function combinations on the stack
work like threads. everything is limited to the sessions though, with
some make-it-easier glue to raw POE events etc.
this was supposed to get into the object layer but i realized that i
don't like writing poe programs without it. i was working on
POCO::Client::FTP and it sucked so much and there were so many handlers...
i did not want to go any further, returning values through
self managed postbacks is no fun at all...
the above approach removes need for several states. it provides synchronisation
to some extend and atomic methods. however people will have to build atomic
operations and locks in sessions should not be possible to make it work
(that means all resources that are to be locked are known at the start and
locks are set for them at the start). you need more for real transactions.
i hope to have working code soon (dont know how much time i will be able
to spend on it).
i would like to hear comments.
torvald
