On Sun, Aug 12, 2001 at 09:03:32PM +0200, [EMAIL PROTECTED] wrote:
> Detaching streams from their sessions is good.
>
> However, I would prefer a real stream model. ATM they represent a source
> or destination including any processing needed (filters, buffers, ...).
>
> It might be better to think of streams as linked processors. Graphs can be
> easily built (multicast, or parallel scanning, ...). There would be interfaces
> that have to be supported by sessions or objects. They are two roles:
> producer and consumer. data travels through the graph, single pieces can
> communicate between each other (flow control, ...).
>
> filter would be plain consumer/producer pieces, you could easily include
> buffers and flow control, windows version could use threads to have
> non-blocking IO on files, ...
>
> Links (associations) between sessions would be needed (and for the
> TODO version as well !). This kinda conflicts with the plans to not include
> object layer features in core POE. But if we decide to go this way, we should
> do it right and discuss more about it, right from the start ...
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.
Perhaps consumers, producers, and links could be something different.
I'd like to see their interaction be as lightweight as possible.
I have the System V streams specification, and I have some notes about
how to pass messages between disciplines on a protocol stack. All my
previous design experiments have assumed protocol layers existed
together in some kind of local chain, not across several sessions.
Please discuss. I'll take lots of notes.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
