On Mon, Aug 13, 2001 at 12:35:34AM +0200, [EMAIL PROTECTED] wrote:
> On Sun, Aug 12, 2001 at 05:47:46PM -0400, Rocco Caputo wrote:
> >
> > I'm inclined to use chained filters to do it. I'm against a complete
> > Session for every discipline on a stream because the $kernel->call()
> > between them will add a lot of overhead.
>
> True. But they could be perl objects dealing with it, embedded in sessions
> in any way. The idea behind that is that developers could freely link these
> pieces and construct various data flow graphs.
>
> > Perhaps consumers, producers, and links could be something different.
> > I'd like to see their interaction be as lightweight as possible.
>
> Yes, they should be lightweigth. But as POE is heading to distributed
> applications (at least I hope so :) the case where data comes from A
> goes over B to C and all that on separate hosts gets more important.
> Imaging being able to easily insert a monitoring component and stuff like
> that. think about aspect/subject oriented programming, ...
> I prefer a slow applications that takes less time to build than vice versa :)
I'm trying to avoid embedded objects in sessions. Wheels do this, and
it makes subclassing POE::Session very difficult. The problem arises
when a new kind of session changes its states' call signature.
Suddenly wheels, which have assumed POE::Session's call signature,
stop working.
In POE::IO::Stream, I'm proposing to move I/O management into a single
dedicated session. All the other sessions would use it in place of
wheels. The TODO file discusses it in detail.
Plug-in pieces and data flow graphs sound like a good idea. I'd still
like them to be as light as possible. Just because POE's useful for
distributed programming doesn't mean that's its only purpose. People
who write one-processor systems should not be penalized, if it's at
all possible.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
