"Ted K." <tedk at wdi.disney.com> wrote:
> > [event graph idea]
> I too have been feeling the need for something
> like this.  Any ideas on how to keep from computing
> the whole graph for each event?

This is only a problem for the "push" arcs of the
graph, not the "pull" ones. My solution would have
a filter (pushInput/pushOutput kind of component)
disconnect from its input (unsubscribe) whenever
it had nobody linked to its output and reconnect
(subscribe) when a new customer arrived. I think
that this (and what you describe below) would avoid
having events flow though any more of the graph
than strictly necessary.

Buffers are a problem (push/pull kind of objects)
because they stay subscribed and grabbing events all the
time, but I don't think anything can be done except not
putting them where they are not really needed.

> I picture the panes of a browser attaching and detatching
> themselves from the keyboard input pipe as
> you move the mouse over them.

That is the idea. It might be best not to take this
too far, however. Windows could work like this and
yet have a single "demux" object distrinute the
events among the subpanes (or submorphs). This would
be a pull/push object - what I have called a "pump".
This scheme has the advantage of being compatible with
a lot of existing code.

> --Ted.

-- Jecel